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

Re: The future of non-dependency-based boot

On Wednesday, April 11, 2012 05:14:34, Thomas Goirand wrote:
> On 04/11/2012 06:12 AM, Chris Knadle wrote:
> >  - if the init script left behind was part of a Debian package, deleting
> > the init script means removing part of the configuration from the Debian
> > pacakge, yet not purging the package it belongs to.  This feels like
> > something that would volate Debian policy regarding one package not
> > altering the configuration of another.
> >   Likewise, moving the init script means that purging the old package
> > that had configuration left behind will no longer delete the init
> > script file, which will thus be left behind as orphaned cruft.
>  You do realize that we are talking about leftovers from Etch (and
> possibly earlier) in Wheezy, which means 4 or 5 years later, right?

I don't disagree that the leftovers are old (whether it be from lenny or 
older)... but will the upgrade script check this?  [Presumably the upgrade 
script would normally only check if the init script is dependency-based 
compatible, and not how old the init script is or whether it's associated with 
a Debian package.]

> If you think that we can't delete them, how about moving them
> away in a special folder, like /etc/init.d/obsolete-scripts (feel free
> to propose a better name for that folder)? We could prompt the
> user about them, so he wont miss it, and the "configuration" that
> you are talking about will stay (even though, most likely, this is
> quite useless, IMO).

I think I agree with this proposition at least in spirit [I'm all for fixing 
the problem, afterall :-P], but I'm wondering whether this is the right thing 
to do or if there's maybe a better alternative.

Personally, I'd rather give the user an option to purge the associated package 
the init script is in (if it's in one), especially if the package has been 
removed-but-not-purged.  If that could be accomplished I think that would be a 
cleaner way of dealing with the problem.

I think another option (which maybe could be used as a fallback) would be to 
leave the broken init script in place, but to 'chmod -x' the file to make it 
non-executable.  [Would this work within the dependency-based framework?]

> >   - the upgrade may be unattended or automatic, in which case presumably
> > the default will be chosen and the user/admin will never know that the
> > init script was removed, so the default of 'yes' is dangerous.
> The default with "no" may be even more dangerous. If you run in a
> non-interactive way, then you will still have some non-LSB header scripts
> on the way, which may prevent you from booting.

I'm trying to figure out a way this can be handled which will conform to 
Debian Policy section 6.3.  Link for convenience:


Between us both, I think we've found that there's a problem with either 
default, which means this is going to be tricky to handle.  :-/

> >   - the current administrator at the keyboard may not be the one that
> > wrote or installed the custom-installed init script, so the upgrade may
> > need to be completed before the question of whether the init script can
> > be deleted has a satisfactory answer, but an answer of 'no' will
> > presumably cause an issue for dependency-based bootup.
> If we move the *bad* scripts away in a specific folder, we have best of
> both worlds, IMO.
> Thoughts?

It's better than deletion, but I'd also like to consdier alternatives.

  -- Chris

Chris Knadle

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: