[Pkg-sysvinit-devel] Bug#706877: insserv: breaks dist-upgrade by installing before packages fix their init scripts

[Lucas Nussbaum]

On 20/10/13 at 09:33 +0200, Petter Reinholdtsen wrote:
> [Jamin W. Collins]
> > It may be bogus or incomplete boot script ordering information, but it
> > previously worked, keep that in mind.  One does not expect a Debian
> > dist-upgrade from one stable release to another to result in a
> > non-functional system.
> 
> Sure.  But the fact that the ordering was not broken when the
> dependencies was ignored do not really matter much.  'ignoring ordering
> loops' is another way to say 'generate incorrect boot sequence', which
> might result in a non-bootable system.  So there is no safe way to
> continue when the boot ordering can not be trusted, and update-rc.d
> refuse to upgrade more packages when this happen as a safe-guard against
> silently breaking the boot (which would only be discovered the next time
> the machine is booted, instead of when the upgrade happen).
> 
> > The former effectively left me locked out of my systems.  I had to
> > reboot every one of them to a single user root session to fix them as
> > my user existed only in LDAP and then unrelated init scripts caused
> > the upgrade to abort in such a way that my user could no longer be
> > validated for sudo.  Had the upgrade proceeded, the system would have
> > been in complete working order (AFAICT).
> 
> Did you run 'sudo apt-get dist-upgrade', and was unable to run a new
> sudo command when the upgrade failed?  Perhaps a safer approach is to
> use 'sudo -i' and then run 'apt-get dist-upgrade' with a root shell to
> make sure you can recover when something go wrong?
> 
> Anyway, I am positive to try to figure out way to avoid breaking systems
> where upgrading packages in a different order would work, but do not
> know which packages have incorrect dependencies in earlier versions
> leading to dependency loops and thus do not know how to do it. :)

Hi,

Is this bug still a problem for wheezy->jessie upgrades?
One could argue that all packages with problematic dependencies could
likely have been fixed during the jessie cycle.

Looking at bugs mentioned in this bug log:
#651037: a duplicate of #650995; fixed in wheezy
#680223: caused by munin-node, fixed in wheezy
#695751: discussion on dependencies on packages themselves depending on
         $all, either implicitely or explicitely (because they would
	 have no LSB headers). There are only a few packages remaining
	 with missing LSB headers[1], and none of them seem likely to be
	 depended. There are more that depend explicitely on $all[2]
	 (lintian has a check for that), and maybe they should be fixed,
	 but again, none of them seem likely to be depended on, except
	 maybe cloud-init. So I believe that in practice, this problem is
	 not so severe.
#589238: several (old) reports of dependency loops. (last activity in
         2011)

Given that this bug was present (unfixed) in wheezy, and the situation
can only have improved since then, I think that this bug should be
jessie-ignore'd.

[1] https://lintian.debian.org/tags/init.d-script-missing-lsb-section.html
[2] https://lintian.debian.org/tags/init.d-script-depends-on-all-virtual-facility.html

- Lucas