Re: Why is help so hard to find?
On Fri, Jan 14, 2011 at 04:07:58PM -0800, Russ Allbery wrote:
> Roger Leigh <rleigh@codelibre.net> writes:
> > I've yet to find a single system which upgraded to insserv cleanly.
> > This is mostly due to removed packages which need fully purging to
> > remove the last traces of old init scripts which break the process.
>
> Huh. Every system I've upgraded had no problems.
I find this strange, since every system that has ever been etch will have
at least libdevmapper1.02 which stops insserv from migrating.
> What is the failure mode? What happens on those systems?
You get a long scary message that makes people search what the heck is going
wrong, but no actual damage. You just stay with the legacy ordering which
currently suffers only from rare corner cases and being undermaintained.
> > This has proven to be the case on every system I've migrated so far, and
> > it is a real pain to identify each offending script and then find which
> > package it belonged to and purge it.
>
> dpkg -S would generally tell you, no? We could document how to do that in
> the release notes.
Documenting would be good -- especially in the fail message rather than in
release notes few people read; however, I think it would be better to fix at
least the common cases.
Sadly, just having insserv Conflicts: the culprits is not enough, a fix
could be one of:
* an otherwise empty package that removes the rc scripts
* Conflicts:+Replaces: in insserv and overwriting the known-buggy scripts
(a nasty hack)
I've suggested having an empty "libdevmapper1.02" before, but I guess I
didn't shout loud enough. I still think it's better to inject it into
squeeze than to suffer people's confusion.
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
Reply to: