Re: Can insserv made better?
At the risk of contributing to what is already often an ill-tempered
and unconstructive thread:
Roger Leigh writes ("Re: Can insserv made better?"):
> You're saying that an unwieldy ad-hoc fixed list of numbers and names
> is superior to detailed dependency information? This is patently
> untrue.
The ad-hoc fixed list of numbers does in some sense contain or
represent some information which is not captured in the explicit
dependencies. This is because the fixed list of numbers has been
"debugged" (including, when irreconcilable problems arise due to
different setups needing different orders, by having arguments about
which setup is more common) to include a lot of dependencies which are
not necessarily declared for the new scheme.
Or to put it another way the fact that the new paradigm is more
powerful and correct does not mean that the _actual data_ we are using
is more correct. Indeed it seems that the actual data for the
dependency-based setup is in many respects less good than the actual
data for the old sequence with the result that arguably the
_actual_ old sequence has fewer bugs than the _actual_ new
dependencies. (Even though some of the old sequence's bugs cannot be
fixed without introducing new ones.)
Why are we insisting on the change to insserv being "recommended" by
the debconf question ?
It seems to me that we should be giving accurate guidance to the user
about a decision that they are to make. That guidance is probably
that:
- On a simple system with default configuration, insserv will
produce a faster boot and is unlikely to break, so is probably a
good idea.
- On a complicated or unusual system, insserv involves a significant
risk of breakage which can be difficult to fix - and the change
cannot be reverted. So it is not a good idea.
Furthermore, why does this debconf question have such a high priority?
High-priority questions should be used only for matters where there is
no good default. But existing systems which are currently working
will not be broken by doing the squeeze upgrade but not switching to
insserv - so there is a perfectly good default, which is not to
switch.
> Your (rejected) patch was not addressing the issue. Documenting the
> pros and cons of moving to dependency-based boot is entirely beside the
> point: we have moved to dependency-based boot. *Your* choice is not if
> to move, but when. [...]
New installs get insserv by default. During the lifetime of squeeze
we can hope that users of those new installs will file bugs for
missing dependencies as they discover them.
It seems to me that for existing installs, the best choice would be to
wait _at least_ until after sqeeze.
> I can't say I'm the biggest fan of insserv myself, but that's what
> is currently supported, and if you want something different, then
> you'll need to step up and start doing the work yourself. I do hope
> we'll have systemd (preferred) or upstart post-squeeze, but I don't
> see /any/ value in returning to fixed-order scripts:
No-one is suggesting "returning" to them, in the sense that no-one is
suggesting that any system which has changed to insserv (and still
works!) should be changed back.
But perhaps it would be wise to review our choice of defaults in the
light of our experience of the quality of the software ?
> we lived with their multitude of deficiencies for decades,
> and now we have a working solution to that. Your efforts would be best
> focussed on finding, fixing and reporting any issues which are causing
> you problems, not griping about decisions which were already taken. It
> was changed in July 2009 for crying out loud! You've had 18 months to
> report any issues?
That some people here did not report and/or fix bugs, is no excuse for
giving all of Debian's users suboptimal defaults. Even if not fixing
bugs in insserv is somehow blameworthy, it isn't the users' fault.
The failure of some people here to report and/or fix bugs is no excuse
ramming through a hasty transition to software which may not be of
acceptable quality.
Ian.
Reply to: