[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cryptdisks(-early) initscripts, dependencies and loops



[Jonas Meurer]
> to make it short: current dependency based boot system doesn't
> provide a solution to this complex issue in my eyes.
> 
> so i'm hereby asking for advice how do adress these issues. should i
> simply tag the bugs as wontfix, describing that a solution is
> impossible? maybe i could write a paragraph for README.Debian, which
> describes the problem and encourages users to fix the issue locally,
> just as the submitter in bugreport #576646 did.

So, what you are saying is that there are requests for all kinds of
boot script orderings, and you would like to find a way where you do
not have to chooce one.  With the way the boot system in debian work,
and has worked since Debian was created, the boot scripts run in some
given order, and the package maintainer have to choose some ordering.
This was true before dependency based boot ordering, and continue to
be true with dependency based boot ordering.  It is also true with
parallel booting, where the declared ordering is enforced and scripts
not declaring any ordering regarding each other are executed in
parallel.

So, for me it is fairly simple: You as the package maintainer have to
decide which order you want your scripts to have in the boot, declare
this using the init.d script dependencies, and stick to it.  This is
also true when one declare the ordering using sequence numbers, and
the only new thing with dependency based boot sequencing, is that it
is possible to detect when package maintainers declare conclicting
ordering, which in effect leads to a dependency loop and an impossible
boot sequence.

Those wanting another ordering can edit the init.d scripts directly to
declare some other ordering or provide override headers in
/etc/inssserv/overrides/ if they want to avoid editing in the
conffiles included in the package.

It is possible event baset boot sequencing might make it easier to
change the ordering, but also there the maintainer of a package need
to decide on some ordering.

Happy hacking,
-- 
Petter Reinholdtsen


Reply to: