Re: The future of non-dependency-based boot
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?
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).
> - 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.
> - 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?
Thomas
Reply to: