Arch Linux User Repository

Well... it seems I had an old version in /usr/local and it conflicted with the newer version. Seems to work with kerberizer packages and seems like my disk is 96% used :) fragmentation? who cares for a system mainly used for save once/don't read often.

I tried to remove the zfs packages from demizer repo and build the git packages using kerberizer. Had to modify the version for the zfs-modules-git and spl-modules-git but not on the two others ? After the installation, zfs import was crashing with an error. I will be coming back to demizer version but they require a different version of the kernel...? I am lazy and this will be working back in a few days so I will wait I guess.

@demizer - switching to the -git packages sounds like a totally sane approach. Take it easy and hope you have a speedy recovery. Thanks for all you do here. My laziness likes the convenience of the repo so that I don't pull any kernel updates until I know the zfs stuff is building for it - especially useful if running with a zfs root.

@WhiteKnight, I will continue to update demz-repo-core, only the packages will be based on the zfs-git packages that we will begin to support. @kerberizer, The upstream git master branch is stable. Before patches are merged into the master branch they are tested. In the years I have been using ZOL, I have never had a problem using patches from the master branch. As far as the zfs, zfs-utils, spl, and spl-utils packages, I think they should be deleted too. We would have to record somewhere our reasoning for no longer updating these packages or following the ZFSonLinux.org release model. So for the record, on the next kernel bump, I will create the following packages (using kerberizer's existing work posted below) that use the "replaces" PKGBUILD variable: zfs-git zfs-utils-git spl-git spl-utils-git I will update these packages on every kernel bump so the changes propagate. The demz-repo-core packages will be based on these packages.

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.

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.

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

@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).

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.

@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).