Hi,
I took over the package blink1. It is not a -git package so it should have a stable checksum, in my opinion. But since the project it builds uses a submodule, the package uses source=("git+https:/…) and SKIP for the checksum. This way prepare() can do a submodule init and submodule update.
Is there a better way to deal with submodules? Or would it be better to download the released binary for the correct architecture and install that? As I currently understand it this would only be acceptable for a -bin package, wouldn't it? (I found no clear guidance when to use that prefix, e.g. zoom)
This is my first AUR and I'd like to do it properly.
Best, Christian
On Sat, 6 May 2023 12:54:42 +0200 Christian syphdias+archlinuxml@gmail.com wrote:
Hi,
I took over the package blink1. It is not a -git package so it should have a stable checksum, in my opinion. But since the project it builds uses a submodule, the package uses source=("git+https:/…) and SKIP for the checksum. This way prepare() can do a submodule init and submodule update.
Is there a better way to deal with submodules?
https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules still applies
Or would it be better to download the released binary for the correct architecture and install that? As I currently understand it this would only be acceptable for a -bin package, wouldn't it? (I found no clear guidance when to use that prefix, e.g. zoom)
If the source is available, the normal package should use it and using upstream binaries should be a -bin package. If the source isn't available, there's no need for the -bin suffix since only one package is going to exist.
Doug
Hey Christian ;)
I took over the package blink1. It is not a -git package so it should have a stable checksum, in my opinion. But since the project it builds uses a submodule, the package uses source=("git+https:/…) and SKIP for the checksum. This way prepare() can do a submodule init and submodule update.
This is described in the package guidelines[0], you resolve the tag to the git commit it points at and pin that. So the package still does have SKIP in the checksum array but you get similar stability guarantees since you pinned the exact commit you packaged.
If you need an example you can look at the PKGBUILD for pawxel[1].
Is there a better way to deal with submodules?
See Dougs answer for the other tip regarding submodules and the source array!
Or would it be better to download the released binary for the correct architecture and install that? As I currently understand it this would only be acceptable for a -bin package, wouldn't it? (I found no clear guidance when to use that prefix, e.g. zoom)
This is then a different package, so its blink1-bin instead of blink1 since generaylly if you download a binary (for software where the source is availiable) the -bin suffix should be used as per the AUR submission guidelines![2]
This is my first AUR and I'd like to do it properly.
Two other small points regarding the PKGBUILD on a quick glance would be: - there is a duplicate source array - you miss the Maintainer: comment (also see [2] for that)
Cheers, Christian / gromit
[0] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_sources [1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pawxel [2] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...
Hi Doug, hi Christian,
Thank you both for your help.
https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules still applies
Basically I missed the last point on the general package guidelines [3].
This is described in the package guidelines[0], you resolve the tag to the git commit it points at and pin that. So the package still does have SKIP in the checksum array but you get similar stability guarantees since you pinned the exact commit you packaged.
So it is best practice to not use the tag itself, since the target commit can be changed, but use the rev-parsed version. Especially since I do not own the source project.
I wanted to ask why you did not do the same way for all submodules in pawxel[1], but I can answer that myself. Since you already pinned by using rev-parsed tag for the main repo, it does include the commit hashes in the commit (tree) and you can just check out the right commits. Basically the perfect example!
- there is a duplicate source array
- you miss the Maintainer: comment (also see [2] for that)
Yeah, I noticed. Already addressed these locally.
Thank you both for the help, Christian
[0] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_sources [1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pawxel [2] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi... [3] https://wiki.archlinux.org/title/Arch_package_guidelines#Additional_guidelin...
participants (3)
-
Christian
-
Christian Heusel
-
Doug Newgard