Ubuntu 14.04 LTS - insserv package questions/conditions

[Tom H]

On Sun, May 18, 2014 at 7:30 PM, Michael Fox <michaelf at heimic.net> wrote:
>
> I've come across an interesting situation and I wanted to know if this
> seemed like a couple of legit issues...
>
> root at hotel:~# lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 14.04 LTS
> Release:        14.04
> Codename:       trusty
>
> I had a default install on Ubuntu 14.04 in which didn't have insserv
> installed, so I installed it, as I wanted to test something however post the
> install I noticed that insserv cannot be executed, as it seems to be outside
> the root users path.
>
> Below is a list of the files that the package contains;
>
> root at hotel:~# apt-file list insserv
> insserv: /etc/bash_completion.d/insserv
> insserv: /etc/insserv.conf
> insserv: /usr/lib/insserv/insserv
> insserv: /usr/share/doc/insserv/README
> insserv: /usr/share/doc/insserv/README.Debian
> insserv: /usr/share/doc/insserv/changelog.Debian.gz
> insserv: /usr/share/doc/insserv/copyright
> insserv: /usr/share/insserv/check-archive-initd-scripts
> insserv: /usr/share/insserv/check-initd-order
> insserv: /usr/share/insserv/make-testsuite
> insserv: /usr/share/insserv/seq-changes
> insserv: /usr/share/man/man8/insserv.8.gz
>
> Below is the $PATH contents for my root user, which won't of course contain
> /usr/lib/insserv, thus we will never see the binary/script needed.
>
> root at hotel:~# echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
> root at hotel:~# which insserv
> root at hotel:~#
>
> I wonder why the bash completion is not working, and why the packager put
> the binary into the path they did?
>
> In addition, if I now wish to remove this package I cannot as I seem to have
> a forced dependence for which I cannot avoid.
>
> root at hotel:~# apt-get remove insserv
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  cron : Depends: upstart-job
>  sysv-rc : Depends: sysvinit-utils (>= 2.86.ds1-62)
>            Depends: insserv (> 1.12.0-10) but it is not going to be
> installed
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused
> by held packages.
>
> If I force it;
>
> root at hotel:~# dpkg --force-all --remove insserv
> dpkg: insserv: dependency problems, but removing anyway as you requested:
>  sysv-rc depends on insserv (>> 1.12.0-10).
>
> (Reading database ... 66047 files and directories currently installed.)
> Removing insserv (1.14.0-5ubuntu2) ...
> Processing triggers for man-db (2.6.7.1-1) ...
> root at hotel:~#
>
> But next use of the apt-get tells me i need to correct an issue..
>
> root at hotel:~# apt-get upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> You might want to run 'apt-get -f install' to correct these.
> The following packages have unmet dependencies:
>  sysv-rc : Depends: insserv (> 1.12.0-10) but it is not installed
> E: Unmet dependencies. Try using -f.

I have installed by default (from the Live 14.04 disk):


# dpkg -l | grep sysv
ii  sysv-rc
2.88dsf-41ubuntu6                                   all
System-V-like runlevel change mechanism
ii  sysvinit-utils
2.88dsf-41ubuntu6                                   amd64
System-V-like utilities

# dpkg -l | grep insserv
ii  insserv
1.14.0-5ubuntu2                                     amd64        boot
sequence organizer using LSB init.d script dependency information

# dpkg -L insserv
/.
/etc
/etc/insserv.conf.d
/etc/insserv
/etc/insserv/overrides
/etc/insserv.conf
/etc/bash_completion.d
/etc/bash_completion.d/insserv
/usr
/usr/share
/usr/share/insserv
/usr/share/insserv/check-archive-initd-scripts
/usr/share/insserv/make-testsuite
/usr/share/insserv/seq-changes
/usr/share/insserv/check-initd-order
/usr/share/man
/usr/share/man/man8
/usr/share/man/man8/insserv.8.gz
/usr/share/doc
/usr/share/doc/insserv
/usr/share/doc/insserv/README
/usr/share/doc/insserv/README.Debian
/usr/share/doc/insserv/copyright
/usr/share/doc/insserv/changelog.Debian.gz
/usr/lib
/usr/lib/insserv
/usr/lib/insserv/insserv
/var
/var/lib
/var/lib/update-rc.d


Before using insserv on Ubuntu:


https://lists.ubuntu.com/archives/ubuntu-devel/2014-May/038265.html

I'm currently merging sysvinit with Debian. The current versions of
update-rc.d now entirely dropped support for the old static SysV
rc?.d/SXXservice ordering/numbering and only support insserv, which
computes the "XX"es according to the dependencies specified in the LSB
headers. I tested that on my workstation, some VMs and some scenarios
in a chroot (the latter without booting, of course), and it works
quite nicely.

So in case we want to follow Debian here, we should revert our delta
in insserv to move /usr/bin/insserv to /usr/lib/insserv/ (to avoid
breaking auto-synced packages and wrong paths in update-rc.d), or keep
the changed path, try and get it into Debian, and adjust update-rc.d
accordingly. Also, our update-rc.d delta would entirely disappear.

Does anyone see a reason to not follow Debian here? If so, we'd need
to basically maintain our own update-rc.d; the current one gets broken
more and more as a lot of packages don't specify a default XX priority
any more and rely on insserv, it doesn't have systemd support, etc.
This might also mean that we need to find and fix Debian-imported
packages which don't work with the implied default priority "20".

Please note that this isn't specific to using sysvinit for booting;
upstart and systemd also use the rc?.d/[SK]XX ordering.


https://lists.ubuntu.com/archives/ubuntu-devel/2014-May/038266.html

Petter has mentioned recently that he plans to move it off the path for
Debian as well.

The reason for the delta in Ubuntu on insserv is documented in the
changelog:

  * Add 200_hide_insserv_on_ubuntu.patch: Move insserv out of system path
    to dissuade package maintainers from invoking it directly. (LP:
    #897390)

Third-party packages were invoking insserv from their maintainer scripts in
violation of the defined package interfaces.  This led to filesystem
corruption and dataloss on shutdown, because insserv is *not* supported in
Ubuntu (and never has been).

We should aim to get back in sync with Debian on this, but doing so depends
on first restoring the init scripts that have been dropped from Ubuntu as
part of the implementation of upstart, so that insserv has enough
information to actually run scripts in the proper order.