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
Chris.Knadle@coredump.us
Reply to: