---------- Forwarded message --------- From: Rich <rincebr...@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 <lu...@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 <lu...@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.