[PKG-OpenRC-Debian] Bug#811708: init-system-helpers: file conflict with openrc: /usr/sbin/update-rc.d

Andreas Henriksson andreas at fatal.se
Wed Jan 20 09:07:36 UTC 2016


Hello Adam Borowski.

Thanks for your bug report. I'm sorry I missed openrc.

On Wed, Jan 20, 2016 at 01:46:08AM +0100, Adam Borowski wrote:
> Package: init-system-helpers
> Version: 1.25
> Severity: serious
> Justification: Policy 7.4
> 
> Hi!
> 
> Unpacking init-system-helpers (1.25) over (1.24) ...
> dpkg: error processing archive /var/cache/apt/archives/init-system-helpers_1.25_all.deb (--unpack):
>  trying to overwrite '/usr/sbin/update-rc.d', which is also in package openrc 0.18.3-1
> 
> 
> It's not a case of a simple move, as the file in openrc is different and has
> openrc specific contents.

It seems like openrc is following the old approach also taken by file-rc
to fork and conflict as I understand it was in the old days recommended.
(I'm not really sure that this was properly policy compliant. In my view
the Conflict/Replaces needs to be set up in *both* directions, not only
in one of the packages.)

I think this is a bad approach and think the way upstart and systemd
handled it by incorporating support in the same program is better.

Some random reasons for this:
 - not everyone can conflict with sysv-rc (see e.g. systemd actually declaring
   a  *dependency* on sysv-rc). And I think Conflicting with
   init-system-helpers will also be problematic.
 - just because openrc is installed doesn't mean openrc is actually running
   (specially not when the package is first installed and even if it's been
    rebooted and has claimed /sbin/init someone might have still overriden
    init via kernel cmdline).
 - keeping state in sync, eg. as done by systemd and sysvinit, so you can
   switch back and forward seems like it becomes more troublesome.

Do you think it would be possible for open-rc to incorporate its
invoke-rc.d and update-rc.d into the init-system-helpers version
so we can all help out maintaining one version instead?

If you still think it's better for openrc to ship its own versions of
these programs, could you please consider switching to using a proper
divert? If you could also runtime detect if openrc is actually running
(how do you do that by the way?) and forward the calls to the diverted
version if not would be good as well IMHO.
A divert would have the benefit of also avoiding problems like the one
you reported in the future, no matter which package ships the progams.

I'm willing to help out on the init-system-helpers side if needed (although
I'm not maintaining it).

Which way do you think is best way forward?

Regards,
Andreas Henriksson



More information about the OpenRC-devel mailing list