Package renaming and -bin suffix questions

germoney · 2021-10-27 05:03:28

Hello! I've already asked yesterday on #archlinux-aur, but since nobody has replied yet with a definitive answer, I'm opening this thread here, too.

I'm the author of an application which I'm also the maintainer of its AUR package for. I didn't originally create the package though and inherited ownership after the package creator gave me co-ownership and then stopped maintaining it because I was doing it all the time anyway.
The package was created in 2015 and then got renamed in 2016 after the application name got changed.

Here's the problem:
My package is actually a -bin package, but it doesn't include the -bin suffix. During the time when the package was created by the original package creator, the -bin suffix for PKGBUILDs which download pre-built binaries wasn't mandatory (AFAIA). This rule was added to the wiki in May 2019, according to the page's change log.

I've been aware of this issue for ages and finally want to fix it, but there are two issues:
First, I don't want the users of my application to miss future updates of my application when I change the name of the package via a merge request after creating the -bin package. That's why I first want to bump the pkgrel and add a block-comment to the top of the PKGBUILD with further information. I could either wait for a week or two and then file a merge request to move the votes and comments over to the new package, so that everyone will have had enough time to see the message and switch packages, or I could continue the non-bin package and build the application from source from the point release. I already maintain the -git package of my app, so there's not much for me to do in terms of writing prepare and build hooks.

However, the big problem with the non-bin package is that my application is based on NW.js (formerly called node-webkit - which is the predecessor of Electron in case you don't know) and my application embeds pre-built NW.js releases of a certain version that is defined by its build config instead of relying on a globally installed/packaged NW.js version. This means that if I continue with a non-bin package, it has to pull the pre-built NW.js stuff in the sources array, and I am not sure if this is the right thing to do for non-bin packages, even though the package is building my application code from source. This version specific stuff is the reason why there are multiple packages of Electron in the official repos too, so that applications are able to target specific Electron versions.

One suggestion by someone from the IRC channel was packaging the specific NW.js version as well and adding it as a dependency, since there's only one package for the latest NW.js version on the AUR which I can't (reliably) use. This would however require me to maintain this additional package which I don't really want, and once my application changes the NW.js version, I will have to abandon/orphan this version-specific NW.js package again. This doesn't sound all that great and I would have to create and orphan lots of packages throughout the entire time. That sucks.

So my question is:
Is it against the AUR submission guidelines of a non-bin package to pull pre-built assets which are not part of the application code that's being built but which are required for running it?

Thanks!

Lone_Wolf · 2021-10-27 08:45:49

Interesting question.

Where do those pre-built NW.js binaries come from ?

germoney · 2021-10-27 10:33:01

Lone_Wolf wrote:

Interesting question.
Where do those pre-built NW.js binaries come from ?

These are built by the developer's build infrastructure (this was or still is sponsored by Intel).
https://github.com/nwjs/nw.js#introduction
https://dl.nwjs.io/

nwjs-bin PKGBUILD (doesn't use pgp signature):
https://aur.archlinux.org/cgit/aur.git/ … h=nwjs-bin

Arch Linux

#1 2021-10-27 05:03:28

Package renaming and -bin suffix questions

#2 2021-10-27 08:45:49

Re: Package renaming and -bin suffix questions

#3 2021-10-27 10:33:01

Re: Package renaming and -bin suffix questions

Board footer