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

Re: The future of non-dependency-based boot

On Tuesday, April 10, 2012 05:53:48 PM Thomas Goirand wrote:
> >> WRT actually doing this, the main issues I can see are
> > 
> > I say just abort the upgrade and let root deal with the issues found,
> > it's better than risking clobbering some local change.
> Considering that most (if not all) scripts would be user custom-scripts,
> I'd say that the best way would be to, just move them away on a special
> folder, and execute them one by one, without any particular order, and
> print a huge warning at boot time, saying:

The main place I've seen this problem is not with custom scripts, but rather 
old init scripts from Debian packages due to config files left behind from 
packages that were 'removed' rather than 'purged'.  [You apparently ran into 
this too with and old config file from Bind 8.]

> HEY, we've found crap, please fix! It's there --->
> $whatever-obsolete-script-path
> Of course, that's not ideal, but I believe that'd be our best hope to not
> destroy *too much* old setups during upgrades. My bet is that most
> user-made scripts would not require any dependencies anyway.
> Also, doing the last upgrades of some old boxes, I've myself found that
> I had some rotten bind 8 init scripts, because bind 8 was removed, but
> not purged. That goes on the way to the user (and that annoyed me
> quite a bit). I believe that for packages that have been removed but
> not purged, it's very very likely that the remaining init.d script isn't
> wanted by the user. I'd be for deleting those with a small warning
> (or even better, a debconf message with something like: do you want
> to delete these antediluvian scripts that are still in your box? yes/no
> with yes as default).
> Thoughts?

What I don't like about the idea of deleting the init script by default:

 - 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.

  - 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 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.

Any thoughts on the above?


  -- Chris

Chris Knadle

Reply to: