Package Details: zfs-linux 2.2.6_6.10.10.arch1.1-1

Git Clone URL: https://aur.archlinux.org/zfs-linux.git (read-only, click to copy)
Package Base: zfs-linux
Description: Kernel modules for the Zettabyte File System.
Upstream URL: https://openzfs.org/
Keywords: kernel linux zfs
Licenses: CDDL
Groups: archzfs-linux
Conflicts: spl-dkms, spl-dkms-git, spl-linux, zfs-dkms, zfs-dkms-git, zfs-dkms-rc, zfs-linux-git, zfs-linux-rc
Provides: spl, zfs
Replaces: spl-linux
Submitter: demizer
Maintainer: lightdot
Last Packager: lightdot
Votes: 271
Popularity: 1.16
First Submitted: 2016-04-21 08:45 (UTC)
Last Updated: 2024-10-23 12:35 (UTC)

Required by (19)

Sources (1)

Latest Comments

« First ‹ Previous 1 .. 38 39 40 41 42 43 44 45 46 47 48 .. 79 Next › Last »

kerberizer commented on 2014-04-13 22:53 (UTC)

Sorry for spamming the comments, but it just came to me that if we migrate towards -git packages, the yaourt users will need to use the --devel option. Not sure if that's relevant for the other AUR helpers, and I wonder if it should be considered a problem or not.

kerberizer commented on 2014-04-13 22:36 (UTC)

I thought it might be still helpful to share the PKGBUILDs I've been working on, as a line or two of them may come in handy (I've also tried to optimize slightly a few things)... https://github.com/kerberizer/archzfs-git Mind you, they are NOT to be used blindly! At the very least, they need manually switching to the new systemd zfs.target provided by ZoL, but that's not the only thing that needs additional tinkering. @WhiteKnight: You are welcome! ;) As for the LTS packages, they are necessary anyway, and if I find some time next week, I might give them a try, as it's certainly better for @demizer to concentrate on his recovery right now.

WhiteKnight commented on 2014-04-13 14:40 (UTC)

Thanks for the detailed explanation, @kerberizer. With your words in mind, just forget my asking for LTS packages. :)

kerberizer commented on 2014-04-13 14:24 (UTC)

@WhiteKnight: As @demizer said, the master branch of the ZoL code is considered stable -- or at least as "stable" as Arch Linux itself is, being a rolling release distribution. This means that moving to -git packages shouldn't lower the stability of a non-LTS Arch Linux system below its inherent level. To put it another way, the packages based on release tags (e.g. 0.6.2) cannot make a non-LTS system any more stable that it inherently is, and indeed, due to the need for specific patching with small user base for testing, they might even _lower_ that stability. This means that all people who have so far been happy with the regular packages shouldn't be any less happy with the -git ones. And those who need more stability than that should consider the LTS kernels anyway -- or, even better, a non rolling-release distribution (for example, I personally tend to use older, well-proven versions of FreeBSD for the most critical systems I manage, albeit it's somewhat arguable if that's not simply laziness on my side ;))). BTW, there's one more reason in my view why -git packages are convenient for non-critical systems. They allow for a gradual upgrade process, where new or changed functionality is introduced in small -- and more manageable -- steps, as opposed to the "huge leaps" between two releases, where one has to cope with a multitude of new things at once -- both as pure number and as variation. That's another reason why I prefer either regularly upgraded systems (like the rolling-release distros) or systems that are never upgraded, save for the most critical patches -- and even then only the ones which are relevant to the specific use. As for the "automatic" transition, if I understand the process correctly, it's just a matter of adding one more variable ("replaces") to the PKGBUILD -- nothing fancy here really and no waste of resources either. And it shouldn't involve any manual work. It's also probably worth mentioning that the transition to -git packages is really more an "organizational" or "administrative" issue at the moment -- the packages are in fact _already_ based on the master ZoL branch (and there's no reasonably simple way to avoid this for the 3.14 kernel as @demizer explained earlier).

WhiteKnight commented on 2014-04-13 12:38 (UTC)

What @kerberizer says makes sense from my point of view. Providing LTS packages for the arch LTS kernel sounds like a good compromise, even thou I'd prefer to have the default (non LTS) kernel on my server. But I'm well aware that I cannot demand anything. :) By the way: Please don't get me wrong; I don't have any problems if the transition would require manual work. And I guess, most users here see it like that, too. So I'd suggest to not waste time and energy for some kind of atuomatic transition.

kerberizer commented on 2014-04-13 10:10 (UTC)

@demizer: I fully support what you've written. It's not only a potentially tedious work patching the ZoL releases for each new kernel, but it's also probably more risky in terms of stability, since this is not something that is necessarily widely tested outside of the Arch Linux community. Thus, somewhat paradoxically, the "stable" packages might actually be less stable than the -git ones. So, I'd also vote for moving towards -git (and supporting the -lts as well for those who really need stability). Concerning the zfs, zfs-utils, spl and spl-utils packages, it might indeed be better to delete them in favour of the -git ones. My reasoning is based mainly on version problems. If we are to follow Git master, it becomes quite important on which exactly snapshot of the source tree the package is based, especially during times of high commit activity, when the timestamp of the package can't be used as a more or less reliable indicator. Simply put, the -git type versioning (e.g. 0.6.2.r253.g888f714_3.14-1) is very desirable anyway. I don't have much experience with this, but I suppose we could also use the "replaces" array in the PKGBUILD to have the transition done smoothly for the people who use the repos (that's partially in reply to the question by @WhiteKnight).

WhiteKnight commented on 2014-04-13 09:42 (UTC)

What effect would that have on your repo? ([demz-repo-core])

thunderforce commented on 2014-04-13 02:31 (UTC)

I would vote for using -git packages since that would match the Arch way better. since I'm abroad (in Brazil, home server is in Los Angeles) and / is mounted read only, I will play safe for a while and not try anything that requires a reboot..... but back to topic, I would be willing to help prepare a testing environment (vagrant and virtualbox come to mind) to aid testing releases, if that would be helpful and easy to work with. Thanks for the great work!

demizer commented on 2014-04-13 01:04 (UTC)

@kerberizer, yes I have been thinking about this as well. These packages are now essentially similar to zfs-linux-git. I'm not sure if that is right. Since ZFSonLinux.org takes a long time between releases, the release based model would not work for Arch Linux since Arch uses the newest kernel ASAP. These packages would only be viable on every new ZOL release, after that kernel updates would require the use of patches to fix kernel API changes, which is the method we have deployed until now. The API changes for 3.14 were fixed in the ZOL master branch, but was built upon all of the previous changes over an 8 month period, so there was no easy simple patch to pull in as was done before. So technically, the best solution would be to just build ZFS from git everytime. This is what the gentoo guys do. I'm not sure if we should delete the zfs, zfs-utils, spl, spl-utils packages in AUR and just use zfs-git, zfs-utils-git, spl-git, and spl-utils-git? Since the release based zfs packages won't work on Arch. Let me know what you all think guys! Thanks, Jesus A.

kerberizer commented on 2014-04-12 16:24 (UTC)

@demizer: Are you going to keep following master (i.e. not stick to the "release" tags, like 0.6.3) in the future? I remember you doing that in the past, but then at some point you switched to the 0.6.2 tag. I'm asking because I'm almost ready with a set of {spl,zfs}-{utils,modules}-git packages for those who want to follow the Git master, but this now seems redundant.

« First ‹ Previous 1 .. 38 39 40 41 42 43 44 45 46 47 48 .. 79 Next › Last »