meta: why do RHEL, Centos and Fedora get official packages while Ubuntu and Debian do not

[gdevenyi]

Issue template ignored due to non-applicability

While ZFS packages are "supported" in Ubuntu, they end up being orphaned at whatever version the ubuntu release someone deploys. When critical fixes/updates are released for ZFS upstream, now one has to dance the delicate dance of removing the ubuntu packages and building/installing the upstream packaging, which has been very rough for deb documentation until very recently, or rely on a third-party packager such as https://launchpad.net/~jonathonf or https://xanmod.org/, which relies on those packagers deploying.

Debian seems to be a bit better, however it looks again like older releases don't necessarily have new packages available: https://tracker.debian.org/pkg/zfs-linux

Meanwhile, for RHEL and Centos:
https://github.com/openzfs/zfs/wiki/RHEL-and-CentOS
https://github.com/openzfs/zfs/wiki/Fedora

I'm just wondering why the choice was made to provide such packages, but not do the same for Ubuntu/Debian

[gmelikov]

Debian won't give you new releases on older releases, it's their policy, and it's great. 0.8.4 has already proposed into unstable there https://tracker.debian.org/news/1143879/accepted-zfs-linux-084-1-source-into-unstable. So it looks well for me.

Can't say much about Ubuntu though. But if distro already has packages - we don't need to maintain additional repo. If you want to be bleeding edge - you may look at rolling distros, not at Debian-based ones (or just use Debian Unstable).

There was a ZoL deb repo before ZFS packages were accepted into Ubuntu and Debian.

Maintaining different repo has it's downsides, for ex. with RHEL/CentOS kernel updates and 3rd party repos with modules can't be in 100% sync, which is usually make some pain on CentOS upgrades.

Just my personal point of view on this topic.

[terem42]

You can fork my Debian ZFS repo https://github.com/andrey42/zfs-debian , then pick up the upstream repo of your choice (set it inside workflow), create signing key as described in repo's readme, and then you will have your personal debian package repo, built and tested (no additional infrastructure is requred) on each repo commit, including updates and patches you need to test/add/remove them into patches list. Very easy and gives you complete freedom over features you want. No need to use any PPA.

[sempervictus]

The Ubuntu situation is a little bit messed up nowadays, but the hope was originally that with them picking it up, it would become much more mainstream in Linux distros (kernel can't actually take it - license conflict). Instead, pools created on Arch or other OS' running 2.0+ can't be imported because they're missing features left and right in the old modules. Unless you're building your own kernels with your own userspace (not as much of an issue these days) and carrying your own modules, the safest bet is probably DKMS packages as their modules should override (in terms of load order) the ones shipping with Ubuntu itself. If you're Canonical customer, might have better luck asking them to stay current...

[Evernow]

If you're Canonical customer, might have better luck asking them to stay current...

That's never going to happen, they're basically allergic to keeping packages up to date.

I'm just wondering why the choice was made to provide such packages, but not do the same for Ubuntu/Debian

Afaik, Fedora and RHEL don't provide full ZFS packages by default, while Ubuntu and Debian do.

Why is it the responsibility of the OpenZFS team to keep distros up to date if they already provide their own packages? It's up to the Ubuntu and Debian maintainers to keep it up to date, go complain to them (have fun with that)

[bghira]

what is the value?

[rlaager]

While ZFS packages are "supported" in Ubuntu, they end up being orphaned at whatever version the ubuntu release someone deploys.

This is a feature. Once a version of Ubuntu is released, it is stable. Packages are only changed for security issues, for "serious" bugs (see the SRU process), or to enable newer hardware (see the HWE process, which is opt-in/opt-out depending on the install media you use). (In fairness, I am aware that the SRU process is stretched to bring in new features occasionally.) That said, as a kernel module, ZFS does get upgrades in Ubuntu as part of the HWE process. Debian is basically the same.

If you're Canonical customer

As a system administrator and Canonical customer, the status quo is exactly what I want. I do not want major changes to systems in production use. I want security updates only, and I'll get new features during planned upgrades to new distro versions.

Individual users often have one to a handful of packages that they care a lot about and think the distro should be upgrading within a release. However, each user's list of "interesting" packages is different. Satisfying all those lists means nearly every package would be updating. And almost nobody wants that, as it would mean lots of unpredictable change and instability. If you do want that, you can run some rolling distro or something like Debian unstable.

The solution here is to have opt-in repositories with upgraded packages. Then individuals can opt-in for those packages they care about, while keeping the rest of the system stable. Debian has this in a relatively official way with backports. For Ubuntu, a PPA is a fine solution to this. A PPA (or a directly hosted package repository) can be maintained by third-parties or by the upstream itself. Across various projects, I've seen and used both. For projects other than ZFS, I've maintained one as an upstream and I've maintained my own backports too (public, but not explicitly intended for use by others).

As for why OpenZFS doesn't have first-party Debian or Ubuntu packages... that's mostly because nobody is currently interested in maintaining them. If someone is serious about doing so, I'd imagine the project would welcome that. (I'm not speaking officially on behalf of the project, of course, just speculating.) That said, having done this, I will say that it's trickier than one might think. You ideally want to coordinate relatively closely with the distro packages so that moving from distro to upstream or upstream to distro works correctly. The easiest way to do this is for the upstream repository to just be backports of updated distro packages. But then the upstream repository will lag, which is half of the problem you're trying to solve! So it can be tricky.

[ahrens]

As for why OpenZFS doesn't have first-party Debian or Ubuntu packages... that's mostly because nobody is currently interested in maintaining them. If someone is serious about doing so, I'd imagine the project would welcome that.

We would welcome that!

That said, having done this, I will say that it's trickier than one might think.

I agree. Delphix maintains package definitions for ubuntu packages of openzfs/master, and we've had to work through issues where different decisions have been made about where files should live. But if someone wants to do the work, these package definitions might be a good starting point: https://github.com/delphix/zfs/tree/master/debian (cc: @pzakha)

[terem42]

I maintain my own ZFS debian packages repo, built periodically off the master branch.
https://github.com/terem42/zfs-debian
The repo has Github Actions workflow with entire tests list and apt pushed into github pages, so that github itself serves as apt repository. The repo can be easily forked by anyone interested in maintenance, see instructions how to do it inside repo's README.md

[bghira]

As for why OpenZFS doesn't have first-party Debian or Ubuntu packages... that's mostly because nobody is currently interested in maintaining them. If someone is serious about doing so, I'd imagine the project would welcome that.

We would welcome that!

That said, having done this, I will say that it's trickier than one might think.

I agree. Delphix maintains package definitions for ubuntu packages of openzfs/master, and we've had to work through issues where different decisions have been made about where files should live. But if someone wants to do the work, these package definitions might be a good starting point: https://github.com/delphix/zfs/tree/master/debian (cc: @pzakha)

that doesn't resolve the issue of compatibility with Ubuntu's downstream packages though?

[stale]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[behlendorf]

Closing. As mentioned above we'd love it if someone was serious about providing packages, but as a project this isn't something we can currently take on.