[aur-general] TU application for Caleb, aka alerque

Caleb Maclennan caleb at alerque.com
Tue Jun 15 11:23:56 UTC 2021


On 2021-06-15 04:19, George Rawlinson via aur-general wrote:
> Please remove me from your mailing list too. /s

I would be pleased to remove you from my mailing list, all I ask is two 
small confirmations:

1. Send any small amount of BTC to 32LTd2RsnrgCbcn6TBunxNSgf1AHFz2ddK to 
confirm your email address.
2. Place your affirmative vote for me as TU before you leave.

> Are there any particular packages that you found difficult to
> package? We all have some of these. :D

Of course, not all upstream projects are as sanitary as others. The ones 
I find the most irritating these days are Electron packages. It usually 
isn't *too* hard to setup a -bin package for them, but actual source 
builds that use the system Electron package are harder. I don't think 
I've ever completely failed to get one going but the amount of patching 
and general hackery needed to make them happen varies — and even once 
you do get it they often turn out to be brittle and break frequently as 
either Electron or upstream project updates come down the pipeline. It 
doesn't help that many (not all) Electron projects are hack jobs to 
start with written by people that don't know anything beyond web markup. 
The build systems they include are usually copy/paste efforts cobbled 
together until it "works" — even if the resulting installs are 2 Gig 
behemoths for 4k lines of JS code that's the actual app. To add insult 
to injury some of these include gimmicks like needing to pass some 
customized css/js linter in order to rebuild the sources. Having patched 
the sources to build just the project without embedding Electron you 
have to also figure out how to disable those build steps or setup 
matching linters in the makedepends=(). Yuck yuck yuck.

Have you noticed I'm not an Electron fan? I *can* beat these packages 
into shape but I don't have to like the process.

Beyond that, some upstream projects make a lot of assumptions about the 
host environment, often assuming a containerized environment where 
everything is tailored to *their* liking. Gitlab is a great example of 
this. I got it packaged and updated it for ages before it moved to 
[community], but the constantly changing requirements for exact Ruby 
versions and assumptions about other services (not to mention the ever 
changing databases layout migrations) put it in the "difficult" 
category. Upstream would rather you run their omnibus container than 
package it on bare metal and the resulting difficulty to packages is 
apparent. Mattermost wasn't quite as bad and has gotten better, but it 
wasn't always as easy one to update.

I had some trouble with Go packages early on, but both the projects and 
the language ecosystem have gotten better and those tend to be 
relatively easy now. The issues with the module fetcher writing not 
being separable from build stages without screwing up permissions are 
obnoxious but passable.

> What's your package maintenance/procedure like? I'm always interested 
> in
> seeing how people approach this so I can steal ^W borrow ideas.

I use `aurpublish` to manage AUR repos, plus a couple hand rolled 
scripts. One signs and publishes packages I built to my own package 
repository, the other steps me through the update/build process. The 
process starts by opening my editor (nvim of course) where I bump the 
version and clean up anything else that catches my eye. Then it updates 
checksums and attempts to build the package (both on the host system and 
in a chroot). If that works it installs it (I only build from systems 
where I actually *use* packages, so this works. Once installed I do a 
quick check to make sure nothing broke. For apps this usually means just 
running them and making sure they don't segfault or complain about deps. 
For system services I restart the service and make sure it still 
functions. If that's good then the result gets committed (aurpublish 
taking care of updating the .SRCINFO) and I push to the AUR repo plus my 
aurpublish repo and run the other script to publish the package and 
re-sign my repo.

Does that answer your question? If not I'll refund your BTC from your 
first request (still send the deposit first so I can verify your 
identify of course).

Caleb

P.S. Was it you that approved the mass deletion of anything Google Play 
Music related from the AUR‌ recently without checking which projects 
actually had been updated to work with YouTube Music even if they still 
have GPM in their name or description?


More information about the aur-general mailing list