Re: Please all dependency info into your init.d script
[Toni Mueller]
> Packages may or may not require services, depending on actual
> runtime configuration. Eg. roundup can use one or more out of a
> number of database mechanisms, some of which require external SQL
> servers, and at least one that doesn't.
Correct.
> Request-Tracker may be run at least with MySQL or PostgreSQL, so
> require which?
It should list both, as optional requirements. In other words, it
should include 'should-start: mysql postgresql' (or whatever those
init.d scripts are called).
> What if the configuration specifies one while a "virtual service"
> $sqldatabase (purely fictional) might provide only the other? Should
> we require both? Slapd may require an external SQL server if a
> suitable backend is defined, and I guess that a whole slew of other
> applications have similar problems.
This is not as hard as you make it sound. The init.d scripts that
should start before a given init.d script if present should be listed
as should-start (optional), and those that are always present should
be listed as required-start.
> To me, the one big question is why you want to stick with the SysV
> init script system instead of eg. switching to runit (my personal
> favourite, w/o having looked far, yet - but it's hard to get worse
> than SysV init, so...).
Well, while replacing the boot system might be an interesting goal, I
believe it will be a very long process to get the Debian project to
agree on such change, and even longer to change all packages to use
it. This is the reason I have decided to focus my effort on fixing
the bugs in the current boot system using mechanism that do not depend
on changing a lot of packages, and which will do the least amount of
changes required to fix the problem.
The current proposal is to document dependencies in the init.d scripts
themselves (or override files while we wait for the init.d scripts to
be updated), and then replace the update-rc.d program with a program
that take these dependencies into account when creating the symlinks
in /etc/rc*.d/. This will fix a few long-standing bugs in the current
boot and shutdown sequence.
> IOW, I'm very doubtful that adding this new complexity really solves
> the problem instead of (maybe) making it even worse - worse, because
> the limited usefulness is now offset by increased changes for packaging
> errors and maintenance burden.
Well, some of us have spent quite a lot of time thinking about the
boot system, and personally I have concluded that fixing the current
boot sequence is fixable in the lenny time frame, while replacing it
with a completely new approach is not. I believe rewriting all 843
packages with init.d scripts to use another system is not possible at
the moment, so I focus on the fix that can have most positive effect
in the short to medium time frame.
It is possible to have the sysv boot sequence ordered using dependency
information in that time frame, as it can be done by only updating a
single package while we wait for the package maintainers to add the
most updated information to their package. Providing this information
outside the package it not going to be maintainable, as such
information will always fall out of sync with the package itself, so
it is best to keep it as part of the individual init.d scripts.
At the moment, 473 of 843 (56%) packages already provide the headers
with dependency information, and I expect us to be able to get most of
the rest to include them for Lenny. For the remaining packages, we
can provide override headers outside the package as an interim
solution.
> I suggest that we take a step back and first examine the field and
> determine a solution instead of rushing to action with SysV init
> (for no perceivable gain, imho), and if I can wish something for
> Lenny right now, dropping SysV in favour of a better alternative is
> high on my list.
If you want to work on the boot system, I absolutely welcome your time
and interest. The initscripts-ng alioth project and assosiated
mailing list is the current gathering point. The various boot systems
have been discussed on the list. You might find the discussion there
interesting.
Happy hacking,
--
Petter Reinholdtsen
Reply to: