implement building ABS (non-AUR) packages

[SimonSapin]

rua’s support for maintaining local patches looks great. The approach of keeping a local git branch and merging from AUR with git is unique as far as I know.

I’ve been using customizepkg together with yaourt for similar functionality. Importantly, this also works with packages from non-AUR official repositories (core, extra, etc.) When a new version becomes available, yaourt can automatically fetch PKGBUILD and associated files from ABS, apply local patches, rebuild, and install. Then when pacman is called, that packaged is skipped since it’s already up to date.

Would it make sense for rua to grow support for ABS packages, for the purpose of maintaining and applying local patches? I realize this is a significant increase in the scope of the project.

(Alternatively, do you know of another AUR helper that does this?)

---

In addition to other reasons not to use yaourt, it seems a recent server config change broke this feature: fetching for example https://git.archlinux.org/svntogit/packages.git/snapshot/packages/gnome-terminal.tar.gz returns an HTTP 400 error.

[Morganamilo]

rua’s support for maintaining local patches looks great. The approach of keeping a local git branch and merging from AUR with git is unique as far as I know.

Yay and aurutils support this as well at least.

I would discourage from adding ABS support for the fear of feature creep. Plus there's already a great tool called asp for using the abs.

[SimonSapin]

Thanks, I will look some more into yay and aurutils.

asp looks like it could be good building block, but does not itself automate the scenario of downloading binary updates from official repository except when local patches are configured, in which case rebuild from source with patches reapplies.

Regarding feature creep, that’s totally understandable. It appears to be a design decision of this project to only deal with AUR.

[vn971]

@SimonSapin glad you like the local patch application technique! Works pretty stable indeed. I don't know how/if other clients support that. None seem to advertise this feature. I just tried to use yay, but I couldn't find a way to patch a local package. Maybe you can do it manually if you drop to shell though.

If ABS can be added as a simple self-contained action, it could be considered I think. But it's better to lay out the whole plan before starting to build it, to verify that it indeed suits well. Please do in that order if you'll attempt it.

One big question so far:

• how to deal with split packages? For example, bubblewrap is a split pkgbase. It has one split name that is identical to pkgbase name, thus you can easily access its git repo: https://git.archlinux.org/svntogit/packages.git/log/?h=packages/bubblewrap but you cannot trivially get the same git repo if you look for bubblewrap-suid: https://git.archlinux.org/svntogit/packages.git/log/?h=packages/bubblewrap-suid This is one of the tricky parts with split packages

Also note that upgrades of ABS and other ABS-aware changes will never make it into the client I think. Only building of one specific package, if it's self-contained and integrates well.

[vn971]

So one alternative is to assume that the user is totally aware of split packages and won't have problems with them. Then it'd work like:

• rua buildabs pkgbase
• use the already exisiting review capabilities of RUA, with only a different git address
• internally invoke rua builddir, which would build the package, and review its contents after building

This way, almost 100% of the functionality is already there, so the maintenance cost and complexity seems almost unchanged. Did I miss anything? Is the assumption "pkgbase = what the user wants" valid?

[SimonSapin]

Does AUR have any split packages? How does rau deal with those?

[vn971]

@SimonSapin it uses AUR HTTP interface: https://aur.archlinux.org/rpc

I gave the idea more thought, I think it'd be OK to only support building "pkgbase" as a first step. It'll be the user's responsibility to find the correct name then.

If you'd be willing to write an MR that introduces this subcommand and basically reuses already existing functionality (with a different git address), I think it can be merged. I don't see any problems with it, at least.

[Morganamilo]

Not sure what's so hard about getting the pkgbase of a pkgname. Just query alpm.

[vn971]

@Morganamilo indeed, thanks for the hint!

[vn971]

@SimonSapin would you be willing to work on this? It's fine if you don't, just better to know.

[SimonSapin]

I was hoping for a (set of) tool(s) that would automate the entire workflow of updating ABS packages with local patches: see (through pacman -Sy or similar) that a newer binary package is similar, skip it and get its PKGBUILD instead, merge with local changes, rebuild, and install.

Also note that upgrades of ABS and other ABS-aware changes will never make it into the client I think. Only building of one specific package, if it's self-contained and integrates well.

Limiting rua’s scope is totally understandable. But that feature is only a marginal improvement over the status quo while still being non-trivial to implement, so I likely won’t. Closing this issue as a result, thanks all for the discussion.

---

The (less automated) workflow I settled on is like this:

When first patching a new system package, use asp checkout to get a git repo of its PKGBUILD and associated files. Make changes in a local branch, then build and install manually with makepkg -i -c. In /etc/pacman.conf, add that package to IgnorePkg so that pacman prints a warning when a newer version is available, and does not silently "erase" the local patch with it. When that happens, manually use git pull to update PKGBUILD and rebuild.

It’s a lot more steps, but I have patches for few enough packages that get updated infrequently enough that it’s still the lowest-effort I’ve found.

[vn971]

I'll re-open to think about it a bit more (currently on a vacation).