request for review of PKGBUILD
hi. i'm trying to submit my first package to AUR. my package files are here: ---- https://git.sr.ht/~minshall/aur-orgtbl-query/tree ---- if anyone has a chance to look over my PKGBUILD (and any other of the files), and has any comments, i'm all ears. cheers, Greg
On Wed, 21 Dec 2022 22:38:29 +0300
Greg Minshall
hi. i'm trying to submit my first package to AUR. my package files are here: ---- https://git.sr.ht/~minshall/aur-orgtbl-query/tree ----
if anyone has a chance to look over my PKGBUILD (and any other of the files), and has any comments, i'm all ears.
cheers, Greg
The only real issue I see is using $pkgdir in the build function. It's not well defined at that point, and should not be relied on. Using that as a prefix doesn't really make sense anyway, prefix is for the install location, such as /usr/ or /opt/$pkgname/. Other than that, some simplification: Lines 44 and 49-53 can all be replaced by just install -Dm644 LICENSE -t "${pkgdir}/usr/share/licenses/${pkgname}/" You should remove empty functions (prepare) and variables (checkdepends and md5sums) All of the other files, (LICENSE, Makefile, README.*) are extraneous and aren't really going to do anything in the AUR. I didn't try building it, but overall, it looks good! Doug
Doug, thanks for the reply.
The only real issue I see is using $pkgdir in the build function. It's not well defined at that point, and should not be relied on. Using that as a prefix doesn't really make sense anyway, prefix is for the install location, such as /usr/ or /opt/$pkgname/.
ah, thanks. i notice (now) the prototype in "Arch package guidelines" ---- https://wiki.archlinux.org/title/Arch_package_guidelines ---- has a build function that does `./configure --prefix=/usr`. is that safer than a plain `./configure`? or, does `make DESTDIR="${pkgdir}"/ install "strong enough" to (typically) deal with the default used by `./configure`?
Lines 44 and 49-53 can all be replaced by just install -Dm644 LICENSE -t "${pkgdir}/usr/share/licenses/${pkgname}/"
thanks. i had seen others using `install` in this way, and had thought of looking at the man page to understand.
All of the other files, (LICENSE, Makefile, README.*) are extraneous and aren't really going to do anything in the AUR.
right. but, is it okay to leave them there? it seems like having them there simplifies my life a bit (everything in a single git repository). cheers, Greg
On 2022-12-22 07:03, Greg Minshall wrote:
has a build function that does `./configure --prefix=/usr`. is that safer than a plain `./configure`? or, does `make DESTDIR="${pkgdir}"/ install "strong enough" to (typically) deal with the default used by `./configure`?
Almost all autotools based configure scripts default to a prefix of /usr/local if not otherwise specified. This makes sense as a default for end users directly installing software from source onto their own systems, the base system of which is probably managed by some package manager. That being said /usr/local is not where the system package manager should ever put anything. Distro managed packages should always be in /usr and so forth. Hence almost all the PKGBUILD files in Arch official repos and the AUR have override build system defaults from source packages to set the prefix to be appropriate for package-manager managed paths rather than end user source installs.
right. but, is it okay to leave them there? it seems like having them there simplifies my life a bit (everything in a single git repository).
No, only the PKGBUILD, .SRCINFO, and any patches required to build and not available elsewhere should be part of the AUR repo.
hi, Caleb, thanks very much.
Hence almost all the PKGBUILD files in Arch official repos and the AUR have override build system defaults from source packages to set the prefix to be appropriate for package-manager managed paths rather than end user source installs.
thanks. `./configure --prefix=/usr` it is.
No, only the PKGBUILD, .SRCINFO, and any patches required to build and not available elsewhere should be part of the AUR repo.
that is understandable, though a bit inconvenient in my case. how do people who have some automated process (like me with my Makefile) to produce PKGBUILD and .SRCINFO typically deal with this, structure things? (i don't *think* i saw any mention of this in the various wiki pages; apologies if i missed something.) my knee-jerk reaction is to have my private directory "A" with my Makefile produce PKGBUILD and .SRCINFO in a second directory/repository "B" which points at (has as a remote) AUR, and have some sort of "release" target in the Makefile in "A", which then builds PKGBUILD/.SRCINFO in "B", and runs `git -C "B"` to commit that, push to AUR. are there other schemes people use i might look at, think about, copy? again, thanks for the comments. cheers, Greg
how do people who have some automated process (like me with my Makefile) to produce PKGBUILD and .SRCINFO typically deal with this, structure things? (i don't *think* i saw any mention of this in the various wiki pages; apologies if i missed something.)
The general method is to keep the automation not in the repository (path) where the PKGBUILD and .SRCINFO reside. aurpublish[1] for example helps you set up a single source repository. Any packaging utilities can live in the repository root while subfolders contain the PKGBUILDs. [1]: https://archlinux.org/packages/community/any/aurpublish/
Bert, et al.,
The general method is to keep the automation not in the repository (path) where the PKGBUILD and .SRCINFO reside. aurpublish[1] for example helps you set up a single source repository. Any packaging utilities can live in the repository root while subfolders contain the PKGBUILDs.
thanks. `aurpublish` (and `git subtree`) certainly seem like the direction to go. cheers, Greg
participants (4)
-
Bert Peters
-
Caleb Maclennan
-
Doug Newgard
-
Greg Minshall