Arch Linux User Repository

After discussing with @ajacocks, I've updated the PKGBUILD to remove most patches, I've only kept one patch needed for compilation (similar to the Gentoo ebuild).

If you need a pre-5.2.0 version, please use autofs-git.

@msdzss As per our Code of Conduct [1], please keep a polite and respectful tone. This is all volunteer work and ranting doesn't bring anything to the table. Note that, as stated on the AUR frontpage itself and in multiple place over the official Arch Wiki, AUR packages & content are unofficial and unsupported, so please refrain to falsely engage people's responsibility here.

If you're able to, please try to adopt a more helpful position in the future. If you have suggestion to make or issue to report, do this in a calm and respectful way. You can also just clone and maintain this PKGBUILD yourself locally if you're unhappy with it for whatever reason.

[1] https://terms.archlinux.org/docs/code-of-conduct/#respect

@msdzss Flushing the cache? You mean hit F5????

It's your responsibility to provide a functional upgrade path. I spent month to get autofs to work with my fall-asleep server setup. Wake-On-LAN integration and auto unmounting isn't even possible without writing multiple wrapper scripts.

And every update I fear that this whole fragile mess is collapsing in itself. And now it did. And you response is like the Facebook customer support: "Did you try flushing the cache?"

I think someone more competent should maintain this very important package and bring it out of this AUR build process mess.

I think grawity is right, we are probably packaging a -pre 5.2.0 version here. The patches are basically a subset of the commits since the 5.1.9 release in the upstream git repo: https://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git/log/

These patches are not used in the other distros, such as debian[0], gentoo[1] or even the BLFS section[2].

I'd say to split into two packages, this one which should be the stable release, and another autofs-git if you absolutely need the patches.

[0] https://packages.debian.org/en/autofs
[1] https://gitweb.gentoo.org/repo/gentoo.git/tree/net-fs/autofs
[2] https://www.linuxfromscratch.org/blfs/view/stable/general/autofs.html

Well, it seems that upstream does not know what they're doing, if they expect packagers to accept a "release" which varies over time (in this method the "5.1.9" built today is not the same as the "5.1.9" built last month).

But it doesn't seem to me that this is really the upstream's intended process, since the folder is called patches-5.2.0 it really seems that this just results in building the whole half-done 5.2.0 release, as there's no distinction between security-critical patches and regular development work. I'd guess they're just used to publishing patches in the same way Linux kernel minor versions used to be published as a giant incremental patch on top of mainline release.

Either way, the method to make makepkg re-download a file is to give it a unique local name using name::url syntax, e.g.:

sources=("patch_order_${pkgver}_20260217::https://blah/patch_order_$pkgver")

Doesn't really make sense to re-download it unconditionally, because if new patches were added since last check, then the build will fail anyway because those patches would still be missing from sources. So there's no point in giving it a randomized name; it should be enough to update the name whenever you also update the .patch source URLs (or more precisely whenever you update the sha256sums).

So my suggestion is to only use patch_order during the PKGBUILD update process – the file becomes completely redundant once the list of patches is imported into sources (which you currently have to do anyway), since the sources array preserves the order anyway.

(Still, IMO, if there are any critical fixes, either upstream should publish a new release immediately (like how OpenSSH published 10.2 with just one bugfix) or the individual patches should be picked up as needed. Otherwise it is pretty much a -git or -nightly package when "all" the patches are included.)

@grawity, they have to be part of the build process, as they are often security-relevant.

I definitely see the simplification of using our own logic to determine what is included, but since the upstream posts a patch_order, I'm inclined to use it, with the assumption that they know what they are doing.

I'm definitely open to suggestions and advice, though.

@msdzss, did you try clearing out your cache? I wish that there was a way (that I know of!) to force the build to always redownload the patch_order file, to avoid the wrong version issue.

I'm wondering if those patches even should be part of the build process at all. After all they're not actually part of 5.1.9 – they're what will eventually become 5.2.0 – so effectively this package is just building Git master. (The only difference is that the patches are signed and Git commits aren't.)

I think there are a few options to improve the current situation:

a) build only exact releases, i.e. just the tarball without intermediate patches;

b) build with patches, but remove the patch_order_* file from sources – use it only when importing (i.e. for your PKGBUILD updates), but have the build process look directly at $sources, as that preserves the order anyway:

for $_file in "${sources[@]}"; do
    if [[ $_file == *.patch ]]; then
        patch -Np1 < "$srcdir/${file%%*/}"

This way, whenever new patches are added, the old PKGBUILD will continue to work, building the older revision like it used to.

c) build directly from Git, pinned to a specific #commit= or #tag= (this doesn't have commit/tag signatures but makepkg will still verify sha256sums).

It no longer builds: ==> Validating source files with sha256sums... autofs-5.1.9.tar.xz ... Passed autofs-5.1.9.tar.sign ... Skipped patch_order_5.1.9 ... FAILED patch_order_5.1.9.sign ... Skipped

New patch_order_5.1.9 version imported and new patches added. Thanks again, @hcartiaux.

Thanks @hcartiaux. I'll test this and get the build updated.