Arch Linux User Repository

When requesting changes, please include detailed reasoning for the change.

If you receive this error when trying to build, it is because you have not imported the GPG keys used for verification.

==> ERROR: One or more PGP signatures could not be verified!

You have two options:

1) Import the two keys into your keyring. ArchWiki article. You can find the key IDs in the PKGBUILD file, in the validpgpkeys array. (recommended)

2) Alternatively, you can skip this verification by passing the --skippgpcheck argument to makepkg when building. (not recommended)

I do not understand this discussion. If kernel/ zfs Version Control is so important for you, you should be using the archzfs repo. This repo makes sure that kernel and zfs are always compatible.

@karns: We do agree with you! While IgnorePkg and having an LTS kernel are good protections against ZFS breakage (that I am personally using for now), we do agree that the ideal scenario is that the package blocks kernel upgrades when there are known compatibility issues.

Heck, I even like the idea of conflicts listing kernel versions above the officially supported version as stated by OpenZFS (for instance it would be conflicts=('linux>=6.3') right now), and for all kernels officially by Arch.

The question is not whether this is a desired behavior (I think we all agree), but exactly how to implement this behavior in a way that won't cause other unexpected problems in some cases. So far, we're not sure there's a way.

The problem with using conflicts for that (also answering @Vrakfall) is bad interactions that can happen for users with multiple kernels installed (usually with different versions).

Picture this scenario. Some ZFS user installed kernel 6.3, which broke their system, and switched to linux-lts in the mean time, leaving 6.3 installed. I'm sure there are people actually in this scenario. If we introduce the conflicts to the PKGBUILD right now, their system packages would be left in an inconsistent state, and pacman would try to uninstall either zfs-dkms or linux to resolve it. Uninstalling the former would be pretty bad!

What I'm not sure is whether this approach could work moving forward if we assume that no ZFS user has an incompatible kernel installed (and very strongly warn against the scenario above for the initial transition and assume zfs-dkms users read this?). Maybe it would work? What do you think, @kstolp?

@karns - just install linux-lts in addition to your main kernel of choice. You are then pretty much guaranteed to always have a working zfs system. If you are running zfs it's a good idea not to run a bleeding edge kernel if you want to avoid breakage (as zfs development always lags a little behind new kernel features)

@fryfrog that is a good suggestion, thank you.

Still, I do think there should be a gate built into the package if that is possible.

Why don't you guys just use IgnorePkg? Add it to /etc/pacman.conf and just upgrade them after making sure it is safe?

IgnorePkg = linux linux-headers linux-lts linux-lts-headers zfs-dkms zfs-utils

Just to add to the discussion here: I have (accidentally) bricked my system on two different occasions due to the zfs-dkms and mainstream linux packages not having a matching release cadence with one another. Luckily, the motherboard on my headless machine has an ipmi interface which I can use to fix things on a live USB. But it is an utter waste of my time.

If it is possible to prevent newer or otherwise incompatible versions of the linux kernel from being installed using, it should absolutely be done. It is quite silly to allow pacman -Syu to brick a system when users are encouraged to update on a regular basis.

@eblau: the idea (which has other problems) would be to use conflicts to flag the package if we know for a fact that the ZFS version it contains is not compatible with a specific kernel version (for instance that it fails to build against that kernel), preventing headaches for some users. If we don't yet know whether it builds or not against an upcoming kernel, then we would not include it in conflicts.

You're right that having to do a DKMS rebuild because the AUR package updated just to change the conflicts field is somewhat undesirable (I don't think we had considered that). But it still may be a price worth paying to prevent system breakage for some users. I mean, package re-builds caused solely because a related package / dependency changed happen all the time.

@meithan the timing in this specific case is close. When a linux 6.3 compatible version of zfs-dkms is released, do you add a conflicts line for 6.4, 6.5, ... or not? What if zfs-dkms doesn't change in several kernel release cycles?

AUR packages can be (and are) updated separately. For dkms packages, it doesn't make sense to release a new version just to update the conflicts line.

@eblau: Linux 6.3 was released on 23 April, and as the new kernel started being deployed in particular distros and people tried to build ZFS against it, we quickly knew for a fact that the latest ZFS release doesn't work with it. This package's maintainer, kstolp, reported so on 3 May. In fact, we knew of the incompatibility even before 6.3 came out from the project development issue tracker. And, officially, the latest ZFS release does not support 6.3 (and it would be wise to stick to official support). There's no future prediction at all involved here.

@Vrakfall: what kstolp said earlier is that this could lead to problems in cases where people have multiple kernels installed, such as people inadvertently uninstalling their mainline linux kernel (>= 6.3) as a result of the conflicts. But I'll let kstolp further elaborate on your argument.

@Vrakfall how is the packager supposed to know that zfs-dkms 2.1.11-1 is incompatible with Linux 6.3? zfs-dkms 2.1.11-1 was released before linux 6.3. The packager would have to be able to predict the future.

Often the older zfs-dkms package is compatible with newer kernel versions so blindly adding a restriction to the most recent kernel isn't a good solution.