| Git Clone URL: | https://aur.archlinux.org/zfs-dkms.git (read-only, click to copy) |
|---|---|
| Package Base: | zfs-dkms |
| Description: | Kernel modules for the Zettabyte File System. |
| Upstream URL: | https://zfsonlinux.org/ |
| Licenses: | CDDL |
| Provides: | SPL-MODULE, zfs, ZFS-MODULE |
| Submitter: | isiachi |
| Maintainer: | kstolp |
| Last Packager: | kstolp |
| Votes: | 188 |
| Popularity: | 2.32 |
| First Submitted: | 2015-08-31 12:01 (UTC) |
| Last Updated: | 2025-05-03 09:40 (UTC) |
I do not understand your point, and may be you do not understand my point.
Yes, I think we may not understand each other. But I think it's not productive to keep debating here whether "depends" or "conflicts" is semantically more correct.
Since conflicts won't be added here, my suggestion was to put the conflicts in a separate metapackage, for those of us who want to prevent incompatible kernels.
@snackattack wrote: No, zfs doesn't depend on linux<=6.14, you can use zfs-dkms without linux installed (for example, with linux-lts). However, you cannot use zfs-dkms at the same time as linux=6.15, therefore it conflicts. For gtk, it's perfectly possible to use gtk3 and gtk4 apps at the same time, but you can't use zfs-dkms at the same time as linux=6.15 -- you have to reboot to a non-conflicting kernel.
I do not understand your point, and may be you do not understand my point.
I have multiple kernel installed linux, linux-lts, linux-tkg 6.12 and 6.14 etc. If we would follow your recommendation and add a conflict to zfs-dkms it would mean that I could not install linux 6.15 without removing zfs-dkms. Which would remove the zfs module from all the other kernels as well. That does not make sense.
you can use zfs-dkms without linux installed
You can use zfs-dkms with an unsupported linux installed. I am. I also have linux-lts installed and boot that by default, but sometimes I need to boot the freshest linux kernel. Then I don't mount zfs and I'm aware of the fact. Having an unsupported linux package installed is not a conflict (as it has been pointed out in this thread), because it does not make it impossible to use zfs-dkms.
The thing with the kernel incompatibility is pretty much documented at this point and Arch isn't Ubuntu to make decisions on part of the (power) user. There are workarounds to the issue, because the obvious fix (zfs always supporting the latest mainline kernel) isn't an option.
What is the point you're trying to make, what do you seek to achieve? Prohibit users from having an incompatible kernel installed? That is an unjustified limitation to impose upon them. If you want to prevent updating to an unsupported linux on your system, you are free to do so, you have been supplied with plenty of options just in this comment section. So what's your point, why limit everyone who know what they are doing?
What you describe is a "dependency" and not a "conflict". There are plenty of packages in the AUR and the Arch repos which have a dependency on a specifc version of another package. E.g. There are packages with a dependency on gtk3 but you can still have gtk4 installed in parallel. zfs-dkms has a dependency on linux<=6.14. But you can still have linux 6.15 installed in parallel. This is not possible if you declare a conflict.
No, zfs doesn't depend on linux<=6.14, you can use zfs-dkms without linux installed (for example, with linux-lts). However, you cannot use zfs-dkms at the same time as linux=6.15, therefore it conflicts. For gtk, it's perfectly possible to use gtk3 and gtk4 apps at the same time, but you can't use zfs-dkms at the same time as linux=6.15 -- you have to reboot to a non-conflicting kernel.
@snackattack wrote: I disagree. If you wish to use zfs with linux, then you need to uninstall linux=6.15 and downgrade to linux=6.14. Therefore, zfs conflicts with linux=6.15.
What you describe is a "dependency" and not a "conflict". There are plenty of packages in the AUR and the Arch repos which have a dependency on a specifc version of another package. E.g. There are packages with a dependency on gtk3 but you can still have gtk4 installed in parallel.
zfs-dkms has a dependency on linux<=6.14. But you can still have linux 6.15 installed in parallel. This is not possible if you declare a conflict.
If it is a conflict you have to deinstall linux 6.15 if you want to install zfs-dkms or, vice versa, you have to deinstall zfs-dkms if you want to install linux 6.15. But a deinstallation of any of the two packages in favor of the other is not neccessary. linux 6.15 goes very well along with the zfs-dkms package. They both do not harm each other. It is just that linux 6.15 is not using / can not use zfs-dkms. But that is not a conflict.
@mabod I disagree. If you wish to use zfs with linux, then you need to uninstall linux=6.15 and downgrade to linux=6.14. Therefore, zfs conflicts with linux=6.15.
Anyways, for the use case where we want to prevent incompatible linux and zfs installations, I believe the simplest solution is to use a metapackage like this [1]:
pkgname=zfs-dkms-conflicts
_unsupported_linux=6.15
pkgver=2.3.2
pkgrel=1
pkgdesc="Meta package to install zfs-dkms and prevent installing incompatible kernels."
arch=('any')
license=('CDDL')
depends=("zfs-dkms>=$pkgver" "zfs-utils>=$pkgver")
conflicts=(
"linux>=$_unsupported_linux"
"linux-hardened>=$_unsupported_linux"
"linux-lts>=$_unsupported_linux"
"linux-rt>=$_unsupported_linux"
"linux-rt-lts>=$_unsupported_linux"
"linux-zen>=$_unsupported_linux"
)
This is what I'm using now. If anyone finds it useful, let me know, and I can submit it to AUR.
snackattack wrote: But if ZFS is a critical part of your system, then conflicts seems right, as updating the kernel will cause problems with the package if installed.
No, it is not a conflict of the two packages. If it is a conflict you have to deinstall linux 6.15 if you want to install zfs-dkms or, vice versa, you have to deinstall zfs-dkms if you want to install linux 6.15.
But a deinstallation of any of the two packages in favor of the other is not neccessary. linux 6.15 goes very well along with the zfs-dkms package. They both do not harm each other. It is just that linux 6.15 is not using / can not use zfs-dkms. But that is not a conflict.
I want to share my 2 cents on this topic: zfs-dkms does not have a conflict with linux>=6.15, it has a dependency on linux<=6.14. That is a big difference. Please read how a "conflict" is defined in the arch/pacman space to understand that.
@mabod I read the PKGBUILD page on the Archwiki page again, and the situation still seems ambiguous to me. I think it depends on the use case: if you are occasionally mounting ZFS drives, then depends is right as you just need one compatible linux kernel to use the software. But if ZFS is a critical part of your system, then conflicts seems right, as updating the kernel will cause problems with the package if installed.
Of course this is just theoretical, in practice depends can't be used since linux-lts, etc doesn't do provides=("linux=6.12").
I'd recommend creating a separate package for a hook and adding it as an optional dependency on this one (or zfs-utils indeed) with clear indication of what it does.
@thaewrapt If a separate package is created to prevent installing incompatible kernels, is the hook really necessary? It could just be a dummy package that specifies conflicts=("linux>=6.15","linux-lts>=6.15").
This is exactly how archzfs works AFAIK. It appears to me that you switched from archzfs and now are frustrated that zfs-dkms, which is different in its nature, does not work similarly.
@FrederickZh I wouldn't agree this is exactly how archzfs works, or that I am frustrated ;)
archzfs prevents updating the kernel to a version that is incompatible with their pre-built zfs package; so if their zfs package is built for linux-lts 6.12.27-1, you would be prevented from upgrading to 6.12.28. For my use case, I do not want to prevent linux-lts from upgrading to 6.12.28 -- but it would be nice to prevent it from upgrading to 6.15 which OpenZFS doesn't support yet.
I'd recommend creating a separate package for a hook and adding it as an optional dependency on this one (or zfs-utils indeed) with clear indication of what it does. This way packages would stay as close to upstream as it is now and we have a separate entity to quickly get rid of in case of any problems with a hook.
could you please create a patch with your hook integration in this package that @kstolp can easily apply if he doesn't mind?
@yurikoles Sure thing: https://gist.github.com/Frederick888/8738f8652348f9f205cc5c6636bd3766 (It exceeded the 5000 character limit here.)
The patch applies on zfs-utils, which is more suitable for these things I guess. I also placed them in /usr/share and kept the /usr/local/bin/ path, as it's probably better to only ship them as examples.
A few changes:
vercomp with a simpler, less versatile version I wrote. The original one from StackOverflow was published under the CC BY-SA licence. IANAL and I wasn't sure if that was compatible with the licence of the packaging code (unspecified) or maybe even CDDL. I'm happy to publish my code under 0BSD, which is recommended by the AUR submission guidelinesrg with grep and sed, so it's probably ok to not add another optional dependency to zfs-utilslinux-rt to have 'arch' in its name too, huh)Note that this hook does not protect you from ZFS upgrades leaving old kernels behind though, if you have any.
Pinned Comments
kstolp commented on 2025-04-29 16:56 (UTC) (edited on 2025-05-03 09:40 (UTC) by kstolp)
OpenZFS currently supports Linux kernel versions 4.18 - 6.14, as declared in the META file.
Options if your Linux kernel's version is not within that range:
1) Switch to another Linux kernel, such as
linux-lts.2) Prevent your kernel package from upgrading to an unsupported version until OpenZFS increases the maximum supported kernel version.
3) Modify this package to support your kernel by patching it on your local machine.
kstolp commented on 2023-09-29 00:34 (UTC)
When requesting changes, please include detailed reasoning for the change.
kstolp commented on 2023-01-07 09:31 (UTC)
If you receive this error when trying to build, it is because you have not imported the GPG keys used for verification.
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
validpgpkeysarray. (recommended)2) Alternatively, you can skip this verification by passing the
--skippgpcheckargument tomakepkgwhen building. (not recommended)