[Pkg-zfsonlinux-devel] Bug#915831: Fwd: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure

[Rich]

---------- Forwarded message ---------
From: Rich <rincebrain at gmail.com>
Date: Mon, Dec 31, 2018 at 8:16 AM
Subject: Re: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure
To: Mo Zhou <lumin at debian.org>


Heh. It being installed was not, AFAIK, a deliberate choice.

Attempting to remove it, though, looks...frought.

$ sudo apt remove -V insserv
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
   init (1.48)
   initscripts (2.88dsf-59.9)
   insserv (1.14.0-5.4+b1)
   systemd-sysv (232-25+deb9u6)
   sysv-rc (2.88dsf-59.9)
   sysvinit (2.88dsf-59)
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
   init
   systemd-sysv (due to init)
0 upgraded, 0 newly installed, 6 to remove and 39 not upgraded.
After this operation, 735 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?]

I'm reasonably confident doing this will break any sort of sysvinit
script usage on the whole system, which (presumably) would defeat the
purpose of ever shipping the sysvinit scripts?

It seems like what we might want is an OR dependency on two child
zfs-{systemd,sysvinit} packages - and for those two packages to
conflict with each other (and require the appropriate respective init
packages)? I think that's the right dependency interlock - exactly one
of {zfs-sysvinit,zfs-systemd} installed with the zfsutils-linux
package, probably with Breaks (zfsutils-linux < $NEW_SHINY_VERSION) in
the new children so that zfsutils-linux's new version shows up first,
and we don't have the two new packages trying to step on the old one's
files?

I don't actually know what a "reasonable" Debian system still using
sysvinit and not transitional bits looks like, so I don't know ATM how
to express the appropriate kind of conflict, but since I think(?) it's
still reasonable to have sysvinit compat hooks installed on stretch,
and I think it's also reasonable to not force people to remove all
sysvinit compat packages to install zfsutils-linux, it seems like
breaking the mutually exclusive bits out might be the best option?

(I think there's also a way to just do this with one new sysvinit
child package, that diverts all the systemd service scripts to
/dev/null or similar when it's installed and reverts it when not, but
since it's not clear to me that it'd be simpler to do that,
particularly if you're still having to include enumeration of the
systemd service files you're overriding in the sysvinit package, I
started with breaking them both out.)

Does that all make sense and/or seem correct? I don't think I made any
unreasonable assumptions about what a "correct" transition path to
having sysvinit and/or systemd files around given the prior states and
that having both enabled is probably impractical, but please tell me
if my pants are on my head. :)

(Also, thanks a lot for spending the time digging into this, I had
been hoping to doso over my short winter vacation, but other things
topped the priority queue.)

- Rich

On Mon, Dec 31, 2018 at 5:28 AM Mo Zhou <lumin at debian.org> wrote:
>
> Hi Rich,
>
> I investigated into this issue a bit and it looks like a result of
> messy system where systemd-sysv and insserv are co-installed.
> In insserv/sid, the postinst process will nolonger fail even if the
> same error occurs. The error will disappear if you remove insserv.
> And in your initial bug report, meta infomation told me that you
> use systemd. So please don't co-install systemd-sysv and insserv.
>
> From zfs's side we can do mostly nothing to prevent user from
> co-installing systemd-sysv and insserv, except for a simple
> suggestion.
>
> Does the issue you reported persist even after removing insserv?
>
>
>
> I tried to install zfs tens of times in different virtual machines
> setup in differrent settings. And my conclusion is simply don't
> co-install them.