Add PKGBUILD and publish Arch Linux package?

[nyanpasu64]

I want to install rgb_keyboard on Arch Linux without making difficult-to-reverse systemwide changes through sudo make install. I noticed that another of your repos (https://github.com/dokutan/mouse_m908) has a PKGBUILD. Is it possible to adapt it for this repo and publish it to the AUR?

I'm currently building a PKGBUILD for rgb-keyboard-git to install the latest Git commit, unlike the mouse_m908 PKGBUILD which only installs a specific release. As a result, I'm researching pkgver(), and got lost documenting Arch's pkgver comparison algorithm (bad code consisting of layers of cruft and C string manipulation). Finishing this documentation will be slower than adapting a PKGBUILD directly (which I'm not motivated to do).

[dokutan]

Is it possible to adapt it for this repo and publish it to the AUR?

It should certainly be possible to adapt the PKGBUILD, and as i am using Arch Linux myself, i have some interest in a PKBUILD but have been to lazy and frustrated with the documentation to get it done (the mouse_m908 PKBUILD was done by someone else).

For the pkgver() implementation, after having a look at some existing *-git PKGBUILDs in the AUR, it seems common to use git rev-list --count HEAD to get the number of commits, which should be detected as a newer version if it is larger than the existing one.

My suggestion would be that you open a pull request with the PKBUILD you have been able to implement so i can have a look at it as well and merge it as soon as we get it to work. For publication on the AUR i will have to read the documentation, but that would obviously be the next step.

[dokutan]

I managed to use the mouse_m908 PKBUILD as a template and have added an experimental PKBUILD for the git version to the master branch. It works for me but is ugly in some places, and i would like to hear your feedback (and potentially improve it) before adding it to the AUR.

Edit: you are obviously still welcome to open a PR with an improved version.

[nyanpasu64]

I think I'll send a pull request which fixes your PKGBUILD; there's enough problems that it's easier to send a PR than a list of changes to apply. Also the filename is spelled wrong.

EDIT: Who should push the package, and who do you want listed as a PKGBUILD maintainer?

[dokutan]

Yes, please do that, writing stuff at 3am tends to give results that are far from ideal.

Who should push the package, and who do you want listed as a PKGBUILD maintainer?

I have no final opinion on that, what are your thoughts?

[nyanpasu64]

I have no final opinion on that, what are your thoughts?

I think I've spent more time researching the Arch guides and talking on the Matrix room about "proper" PKGBUILD format, but I don't think I'm going to maintain the package indefinitely. Maybe I'll try to document my understanding and let you submit it, or I could submit it and orphan it if I stop using rgb_keyboard.

Do you prefer the package name rgb-keyboard-git or rgb_keyboard-git? A git pkgbuild is expected to have the suffix -git.

[dokutan]

Then i would suggest that you open a PR and i will submit it to the AUR as that gives me the opportunity to submit the mouse_m908 one as well. I prefer rgb_keyboard-git as the package name, to be consistent with the name of the binary and this repo.

Edit: i would obviously be very thankful about any documentation that you can provide.

[nyanpasu64]

https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Rules_of_submission says the PKGBUILD comments should contain the maintainer's contact info. What's your email? I don't think I should list dokutan <54861821+dokutan@users.noreply.github.com> in the PKGBUILD. (It also recommends replacing @ and . with words to avoid spam.)

EDIT: Alternatively I can send the PKGBUILD in this issue and you can fill out the rest.

[dokutan]

Please add the PKGBUILD to this issue or as a PR to the main repo, i will have to create an account on AUR first and maybe a new email adress and add my info then. But that has to wait until i've slept (no need for new stupid mistakes on my side).

[nyanpasu64]

PKGBUILD is at https://gist.github.com/nyanpasu64/52a05e53da220b299e6ba99fb1c229dc, you'll have to fill in your email yourself. I tested that it installs properly.

Observations

According to the Arch wiki, you're better off basing PKGBUILDs off templates in the example folder. Because this is a Git package, I used /usr/share/pacman/PKGBUILD-vcs.proto, and deleted empty fields (as instructed on the Arch matrix).

(Also you spelled PKGBUILD wrong in the file name.)

You're fortunate that running makepkg directly in the tree doesn't cause folder collisions, since your git repo lacks a src folder which is used by makepkg.

The template I listed above contains lots of ${pkgname%-VCS}, but to avoid repetition, I replaced it with a variable named $_pkgbare. The variable is derived from the package name, and gets used for provides/conflicts, and is used to cd into (but not determine the name of) the Git clone folder.

If you replace the package name with a hyphen, then $_pkgbare will become rgb-keyboard but the Git clone will remain rgb_keyboard and cd commands will result in "folder not found" errors, unless you use source=("rgb-keyboard::git+...") as described in the wiki.

There's mixed opinions on whether depends=(... gcc-libs) should be explicitly listed or not; forum discussion

I think you're supposed to add makedepends=('git'), though it's likely already installed on most systems (it's hard to download a PKGBUILD without Git installed).

makedepends=(make) is unnecessary, since it's in base-devel and packages in base-devel should not be listed.

package() is manually copying the files. The template uses make DESTDIR="$pkgdir/" install, but that fails for this repo because your makefile doesn't use DESTDIR.

Fixing pkgver()

I've been researching pkgver() for longer than I'd like, and git rev-list --count HEAD is not the preferred approach now. The current recommendation is in the Arch wiki article "VCS package guidelines".

How it works is that git describe --long produces a string with format {most recent tag}-{commits since tag}-g{commit hash}, and the recommended sed expression turns it into {most recent tag}.r{commits since tag}.g{commit hash}. The reason behind picking .r# syntax is so that 1.0 < 1.0.r2 < 1.0.1 < 1.0.1.r2.

I'm planning to instead use git describe --long --tags | sed 's/^v//;s/\([^-]*-g\)/r\1/;s/-/./g' for this repository, which accepts un-annotated tags (--tags) since this project has no annotated tags, and removes the leading v prefix from the version number.

Note that "commits since tag" is not monotonic and resets to 0 whenever a new tag is added. The wiki contradicts this by saying that .r# are supposed to be globally monotonic. This can be ignored, since the wiki-recommended Git templates produce .r# which are only monotonic within each tag, and Arch Linux team member diabonas says that's acceptable. (At some point, I'll propose edits to the wiki to explain this more clearly.)

Background: Pacman's version comparison algorithm

The output version comparison algorithm is that versions are split into segments, consisting of non-alphanumeric "filler" followed by either nothing but numbers or nothing but characters. 1.0.r2 is split into ['1', '.0', '.r', '2']. The general rule is that character segments (sorted lexicographically) come before numeric segments (sorted numerically), 1.0beta comes before 1.0, but 1.0.r2 comes after 1.0. (Unfortunately the actual implementation is nearly impenetrable C code, inherited from RPM and modified (bodged) to fit pacman's version numbering and to fix oversights.)

(I have a longer article on Pacman's version comparison algorithm, but it's unpublished and unfinished, covers lots of edge cases and failure modes that real version numbers don't hit, and it's not easy to understand (IMO because the algorithm is confusing).)

[dokutan]

Thank you a lot for your efforts, it should now be available on the AUR. Feel free to close this issue if it works for you and looks ok, otherwise please let me know.

[nyanpasu64]

Seems to work now, thanks for submitting!