ASCII: can't install zfsutils-linux from backports -missing dependency

dev-1-dash-1 · 2020-03-30 21:38:25

ASCII: Can't install zfsutils-linux version 0.7.12-2+deb10u1~bpo9+1 from backports, due to missing dependency.
The package conflicts with package insserv (<1.18), but the highest version of insserv in ascii repositories is 1.14.0-5.4+b1.

Therefore it's not possible to install this newer version of zfsutils-linux without pulling in insserv 1.18.0-2 from beowulf.

Is it safe to use beowulf's insserv on ascii, and if so, why isn't it present in ascii repositories, making it impossible to install latest version of zfsutils-linux?

How to reproduce:
1 Have an ascii system running.
2 Enable backports
3 Install zfs-dkms 0.7.12-2 (from backports) and neccessary packages
4 Try to install zfsutils-linux 0.7.12-2 (from backports).

dev-1-dash-1 · 2020-03-30 21:41:44

Here's aptitude's info screen for zfsutils-linux. It shows it in an already installed state, after I pulled in insserv 1.18 from beowulf.
But you can see , under the line --\ insserv (< 1.18), all versions of insserv present in the official ascii repos, and the only one is 1.14,
which is not compatible with this version of zfsutils-linux.

i    --\ zfsutils-linux                                                                                                                                          0.7.12-2+deb10 0.7.12-2+deb10
  Description: command-line tools to manage OpenZFS filesystems

  Homepage: http://www.zfsonlinux.org/
  Tags: admin::configuring, admin::filesystem, interface::commandline, role::program, scope::utility, use::configuring
  Priority: optional
  Section: contrib/admin
  Maintainer: Debian ZFS on Linux maintainers <pkg-zfsonlinux-devel@alioth-lists.debian.net>
  Architecture: amd64
  Compressed Size: 290 k
  Uncompressed Size: 1,087 k
  Source Package: zfs-linux
  Origin: Devuan Backports:2.0.0/stable-backports [amd64]
  Origin URI: http://deb.devuan.org/merged/pool/DEBIAN/contrib/z/zfs-linux/zfsutils-linux_0.7.12-2+deb10u1~bpo9+1_amd64.deb
  --- Depends (11)
  --- Recommends (3)
  --- Suggests (3)
  --\ Conflicts (6)
    --\ insserv (< 1.18)                                                                                                                                                                      
p     1.14.0-5.4+b1
    --- insserv (< 1.18)
    --- zfs
    --- zfs-fuse
    --- zfs-fuse
    --- zfsutils-linux 
  --- Breaks (4)
  --- Package names provided by zfsutils-linux (1)
  --- Packages which depend on zfsutils-linux (16)
  --\ Versions of zfsutils-linux (3)
p    0.6.5.9-5
p    0.7.3-3+devuan1
i    0.7.12-2+deb10u1~bpo9+1

steve_v · 2020-05-05 06:22:26

FWIW (and admittedly not really an answer to your question), I find it far easier to just build ZFS from upstream sources than to muck about with backports and Debian/merged packages.

./configure --prefix=/usr --enable-sysvinit --disable-systemd
make
make deb-dkms
make deb-utils
dpkg -i ./*.deb

And you get a not-ancient ZFS build to boot. Upstream is at v0.8.3 right now, and there are some nice improvements over the crusty release Debian/Devuan is shipping.

ZFS works just fine on ASCII with insserv 1.14, and it has since 0.6.x, at least with the init scripts from upstream.
Dunno what's wrong with the distro packaging, I don't immediately see a bug report explaining the conflict either.

Last edited by steve_v (2020-05-05 06:24:53)

dev-1-dash-1 · 2020-05-05 11:02:03

steve_v wrote:

FWIW (and admittedly not really an answer to your question), I find it far easier to just build ZFS from upstream sources than to muck about with backports and Debian/merged packages.
./configure --prefix=/usr --enable-sysvinit --disable-systemd
make
make deb-dkms
make deb-utils
dpkg -i ./*.deb
And you get a not-ancient ZFS build to boot.

Thanks for your reply.
I'll keep in mind the fact that it's so easy to build directly from upstream.

Zfs from the official devuan/debian repops always worked fine for me, and I didn't need any particular feature from newer versions, so I just used that. For ascii, the earlier zfs version is ok, just when using the newer one from backports this conflict appears.

My policy is always use the official sources, only compile your own version if you absolutely need it and it isn't there in the official repos.
Or else why would I even be using an apt/dpkg based distro ?

Upstream is at v0.8.3 right now, and there are some nice improvements over the crusty release Debian/Devuan is shipping.

I know it's 0.8.3, and I am already packed and almost ready to move on to beowulf pastures, which has exactly that version in it's backports.

ZFS works just fine on ASCII with insserv 1.14, and it has since 0.6.x, at least with the init scripts from upstream.

On that particular system, I've solved the problem by installing insserv 1.18 from beowulf. That resolved the conflict and didn't break anything (that I would notice).

Dunno what's wrong with the distro packaging, I don't immediately see a bug report explaining the conflict either.

I just thought posting an exact problem report on this forum should suffice.

steve_v · 2020-05-05 12:07:58

dev-1-dash-1 wrote:

My policy is always use the official sources, only compile your own version if you absolutely need it and it isn't there in the official repos.
Or else why would I even be using an apt/dpkg based distro ?

I generally take the same approach, because I like unattended-upgrades. In the specific case of ZFS though, I was using it some time before it was in the (then Debian Squeeze) repos, so I already have a check version -> print new bugs -> compile -> install shell script lurking around. Kept using it when moving to Devuan because it was late into the repos (like everything else), and I don't see a point in changing now.
That and ZFS modules are something I want to manually vet updates for, because I'm a bit of a data-hoarder and my pool is important to me.

dev-1-dash-1 wrote:

I know it's 0.8.3, and I am already packed and almost ready to move on to beowulf pastures, which has exactly that version in it's backports.

Frankly, I've been waiting for beowulf for far longer than I would usually have patience for, at this point my systems are on average only about 85% Devuan I've had to backport so many things.
Moral support is now pretty much the only reason I haven't given up in disgust and moved to something with a sane release cycle.

As much as I do understand the reasons, being stuck with a three year old Debian release for eternity does not make for a nice user experience. Still waiting for that beowulf stable thing...

I've solved the problem by installing insserv 1.18 from beowulf. That resolved the conflict and didn't break anything (that I would notice).

Personally I prefer to backport things myself and/or compile them locally over adding mixed-release sources. That's just me though, there's probably a bad experience behind the it somewhere in the distant past.

I just thought posting an exact problem report on this forum should suffice.

I would have thought the Devuan bugtracker would be a better place, but then the thing is kinda confusing to navigate considering the relationship with upstream Debian bugtracking...
I mean this is probably a Debian bug, right?

Last edited by steve_v (2020-05-05 12:11:16)

dev-1-dash-1 · 2020-05-05 13:19:21

steve_v wrote:

I generally take the same approach, because I like unattended-upgrades. In the specific case of ZFS though, I was using it some time before it was in the (then Debian Squeeze) repos

I only use zfs since jessie, so I started when all the stuff was already conviniently packaged.

Frankly, I've been waiting for beowulf for far longer than I would usually have patience for, at this point my systems are on average only about 85% Devuan I've had to backport so many things.

The beowulf package tree is apparently ready, the thing that's being worked on right now are the install images themselves.
You can use debootstrap (ascii or beowulf version) to set up your system. That's the smallest and slickest install image available, seems to have no bugs right now. I've done so, and everything seems to work fine, including zfs root. As I said, I've almost jumped ship from jessie myself.

Moral support is now pretty much the only reason I haven't given up in disgust and moved to something with a sane release cycle.

Maybe try Arch Linux? I've heard they have more frequent releases...

As much as I do understand the reasons, being stuck with a three year old Debian release for eternity does not make for a nice user experience. Still waiting for that beowulf stable thing...

Seriously though, devuan is working slow and steady. That approach is good for stability. And general health of your systems (including your nervous one).
And yes, I also wish beowulf would be done already.

I've solved the problem by installing insserv 1.18 from beowulf. That resolved the conflict and didn't break anything (that I would notice).
Personally I prefer to backport things myself and/or compile them locally over adding mixed-release sources. That's just me though, there's probably a bad experience behind the it somewhere in the distant past.

Surely that approach is more reliable in general. Had this happened on a production server, I would have done the same or cancelled the upgrade altogether.
I did make a snapshot before the upgrade, ability to do so is the primary reason to use zfs for me.

I just thought posting an exact problem report on this forum should suffice.
I would have thought the Devuan bugtracker would be a better place, but then the thing is kinda confusing to navigate considering the relationship with upstream Debian bugtracking...
I mean this is probably a Debian bug, right?

Devuan team must be working their asses off trying to release beowulf any minute now. Right? I mean they have to be, right?
Let's not disturb them.

After they release beowulf, we can bombard them with bug reports for ascii.

As to whose bug this is, I leave it to the devuan team to comment on this one.

Last edited by dev-1-dash-1 (2020-05-05 13:21:49)

steve_v · 2020-05-05 14:18:08

dev-1-dash-1 wrote:

The beowulf package tree is apparently ready, the thing that's being worked on right now are the install images themselves.

Promising, but I don't run betas on servers... And I don't run Devuan on desktops, because it's simply too out of date.

You can use debootstrap (ascii or beowulf version) to set up your system. That's the smallest and slickest install image available, seems to have no bugs right now.

Honestly, I don't care about install images. I run Gentoo on my desktop(s), I'm fine with a stage-1 tarball. I reinstall servers pretty much never.
What I do care about is running a LAMP stack that still has some measure of upstream support.

Maybe try Arch Linux?

Systemd-only, breaks constantly, requires hand-holding for the most minor of updates, community doesn't understand concepts such as unattended-upgrades or headless servers. Been there. Spent quite some time there in fact.

Seriously though, devuan is working slow and steady. That approach is good for stability. And general health of your systems

What's not good for the health of anyone's systems is having to pull in backports on release-day and resort to local compiles or third-party repos just to get, for example, a version of PHP that anyone anywhere is still using.

There's stability, and then there's being stuck with bugs, security issues, and compatibility problems forever. Debian walks a fine-line on this, Devuan is currently still a fair way over it.

Had this happened on a production server, I would have done the same or cancelled the upgrade altogether.
I did make a snapshot before the upgrade, ability to do so is the primary reason to use zfs for me.

Here's the thing: I do run devuan on production systems.
Snapshots are all well and good, but they're no substitute for properly maintained packages that actually work.
Here's what happens:
Bug is found in Debian package.
Upstream fix makes it into release before freeze, or is not considered worthy of backporting and lands in Sid.
Devuan is stuck with bug for another 2 years because it's tracking oldstable, which only gets critical fixes.

Snapshots are no substitute for shipping software components that are still receiving upstream security support either.
Debian, for example, despite the reputation for ancient packages, bumps their PHP packages roughly in-step (2 years) with upstream security support. Devuan is still shipping PHP7.0, which is now 5 years old and went EOL over a year ago.

How many large upstreams (e.g. all of e-commerce) do you think support running their projects on a stack released in 2015 and no longer receiving patches?
Some of them put up with Debian, because userbase. None make exceptions for Devuan.

Buggering about with polkit/gnome/whatever shiny desktop thing is wanted in the moment is all well and good. Sitting on a release to do so while the server side (i.e. the primary domain of GNU/Linux in general and Debian in specific) rots is not.

Last edited by steve_v (2020-05-05 14:25:14)

The officially official Devuan Forum!

#1 2020-03-30 21:38:25

ASCII: can't install zfsutils-linux from backports -missing dependency

#2 2020-03-30 21:41:44

Re: ASCII: can't install zfsutils-linux from backports -missing dependency

#3 2020-05-05 06:22:26

Re: ASCII: can't install zfsutils-linux from backports -missing dependency

#4 2020-05-05 11:02:03

Re: ASCII: can't install zfsutils-linux from backports -missing dependency

#5 2020-05-05 12:07:58

Re: ASCII: can't install zfsutils-linux from backports -missing dependency

#6 2020-05-05 13:19:21

Re: ASCII: can't install zfsutils-linux from backports -missing dependency

#7 2020-05-05 14:18:08

Re: ASCII: can't install zfsutils-linux from backports -missing dependency

Board footer