Including kernel packages on archzfs repos

[clarfonthey]

It would be nice if, instead of fiddling with compatibility with the kernel packages in core, the archzfs repos just included copies of the latest version of kernel packages that worked with the current builds. Since the "rolling release" model for Arch can't account for new kernel features immediately due to the support for linux-lts, I think it would be safe to just assume that the slightly-older kernel packages should work fine.

[clarfonthey]

Apparently I had no idea that this already existed. Just closing.

[clarfonthey]

I'm actually going to reopen this since it seems that the kernels.archzfs.com repo is kind of buggy. I would prefer if this support were officially upstream, rather than just hosted under the archzfs.com domain.

[jackkamm]

Another problem with kernels.archzfs.com is that it doesn't work with https, only unencrypted http.

This page (which is also linked from https://wiki.archlinux.org/title/security) recommends only using https for package mirrors:

https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview

[WildPenquin]

Perhaps (?) an unpopular opinion / suggestion: don't include kernel packages in archzfs repos.

Rationale:

They are already available in Arch Linux Archive (ALA), and utilities such as downgrade already exist to facilitate downgrading. It doesn't make much sense to double-host kernel packages.

There are users dealing with the issue in their own ways in issue #393 .

Instead, the archzfs repository could include a small script (perhaps one adapted from the ideas in #393) to download the matching kernel(s), according to what the system uses / admin chooses, from the ALA. This would be much cleaner and simpler than relying on a 3rd party repository. The admin could run the script manually, however I find this administration cost small compared to dealing with a 3rd party repository which might or might not be up-to-date. Alternatively, this could be at least partially automated with a pacman hook.

[jackkamm]

"Cleaner and simpler" is subjective. IMO it's much cleaner and simpler to keep the latest compatible kernel in a custom repo and run a single pacman command, rather than have to run multiple pacman commands with different flags, use custom update scripts or pacman hooks, etc.

Anyways, I think this issue should probably be closed, since kernels.archzfs.com exists, and the complaint that it's "buggy" is rather vague. It's been pretty reliable for me over the past 1-2 years, except for one time when the server was briefly down.

I do still think it would be nice if it kernels.archzfs.com supported https, but I'll raise a separate issue for that. Also as #368 points out, TLS doesn't really make things more secure since packages are officially signed -- though the user might want to double check SigLevel in pacman.conf to be sure of that.

[clarfonthey]

I used the "it's buggy" argument because I had just started using it and didn't want to elaborate much, but the real problem is that it's incredibly slow. Since the archzfs project already has several fast mirrors, it would be a huge help to start offering these repos on these official mirrors, since it would dramatically speed up uploads and take the load off of this one server. Instead, we're operating off of a different server that simply exists under the archzfs subdomain.

Additionally, I strongly disagree with downgrading via the ALA being a reasonable solution. The reason why I started using the kernel repos is because I was so, so, so tired of having to manually exclude kernel packages from updates because the ZFS modules lagged behind, and because I had been burned a few times by using the DKMS package on kernels that actually were too new for ZFS to compile properly.

I get that you opt into doing extra work when you use Arch, but knowing that you might need to do extra work doesn't mean that you should be required to do all that extra work when simpler solutions exist. I get that it's not an ideal solution, but it works extremely well and it would be nice if the project officially supported it beyond offering a subdomain.

[AeroNotix]

How can we help with the speed? I get that hosting / serving to unpaying and ungrateful users doesn't sit well. If there's a way to help cover hosting costs/provide alternate hosting - please let me know.

[clarfonthey]

Not quite sure whether your comment is genuine or calling me ungrateful, but my point is that the resources already exist for fast mirrors for the ordinary ZFS packages, and it would be nice to leverage that for the kernel packages instead of relying on the single server of one volunteer.

Like, I don't think that it's reasonable to ask people to pay more out of their pocket to just make things faster, but my point is that people are already paying for these resources and that they should be made available to the kernel packages too.

[AeroNotix]

Not quite sure whether your comment is genuine or calling me ungrateful, but my point is that the resources already exist for fast mirrors for the ordinary ZFS packages, and it would be nice to leverage that for the kernel packages instead of relying on the single server of one volunteer.

Like, I don't think that it's reasonable to ask people to pay more out of their pocket to just make things faster, but my point is that people are already paying for these resources and that they should be made available to the kernel packages too.

Nothing was aimed at you.

[clarfonthey]

All good; I genuinely can't tell in these sorts of discussions, so, I did want to clarify.

I think that ultimately, pooling resources together for the project is a good idea, since it is a net benefit for everyone involved.

[jackkamm]

Coincidentally kernels.archzfs.com stopped working around the time of the last comments in this thread. Hope it can be fixed soon. Here is the issue:
endreszabo/kernels.archzfs.com#8