Hello my name is Jason. I just published my first package to the AUR. It is a text-processing program called fql. I was surprised how simple it was. I'm pretty good with bash and have previously maintained a personal Linux from scratch build so I'm pretty good at getting things complied.
I was wondering if there is a place (or if this is that place) to find packages in need of a maintainer?
if anyone has a minute to look at my PKGBUILD, that would be great. One of the tools listed in the wiki said it was missing something about contributors so maybe I missed a variable? Otherwise, I think I got it right.
On 10/09/2021 23:19, Jason Kercher via aur-general wrote:
I was wondering if there is a place (or if this is that place) to find packages in need of a maintainer?
Have a look at the orphaned package list, https://aur.archlinux.org/packages/?O=0&SeB=nd&K=&outdated=&...
J
Thank you Jonathan. I see a lot of the orphans are for arm64, but I don't own an arm board. I assume makepkg can be configured for cross-compiling... Is it okay to maintain packages that way?
On Fri, Sep 10, 2021, 7:44 PM Jonathon Fernyhough via aur-general < aur-general@lists.archlinux.org> wrote:
On 10/09/2021 23:19, Jason Kercher via aur-general wrote:
I was wondering if there is a place (or if this is that place) to find packages in need of a maintainer?
Have a look at the orphaned package list,
https://aur.archlinux.org/packages/?O=0&SeB=nd&K=&outdated=&...
J
On 2021-09-10 20:37, Jason Kercher via aur-general wrote:
Thank you Jonathan. I see a lot of the orphans are for arm64, but I don't own an arm board. I assume makepkg can be configured for cross-compiling... Is it okay to maintain packages that way?
You can safely ignore those. There are many, many more pages beyond that first one that are ripe for the picking. It would also be of help to submit requests for old, dead, unmaintained packages to be deleted :).
Hey Jason,
On Fri, Sep 10, 2021 at 07:19:16PM -0400, Jason Kercher via aur-general wrote:
if anyone has a minute to look at my PKGBUILD, that would be great.
A couple of suggestions:
- Variables which are empty or set to their default values (e.g. pkgver=1.0) aren't needed. I'd recommend only setting those you actually want to set. - "provides=(libfql.so)" seems odd to me. The "provides" key is used when your package provides a drop-in alternative for another package, but there's no libfql.so package. You can probably just remove that one. - The "$pkgname-$pkgver.tar.gz::" in source= isn't needed, as the archive already is named that way, so no need to rename it. - If you use $pkgver in the source URL, you'll only need to adjust that, once a new version gets released, rather than also having to adjust the URL. - The "prepare" function does nothing and can be removed. - Setting of "prefix=" in build() seems weird. I'm not even sure if you can rely on the pacman -Ql output (and e.g. sorting) like that. Why not just set it to /usr, since you *know* where the package you depend on installs its files? - Why the "sudo" in "sudo make install"? You don't need root privileges to package something. If you do, then your PKGBUILD is trying to write files outside of $pkgdir, which would be bad.
As for maintaining other packages, I'd suggest only maintaining things you actually use yourself. Look for packages installed on your system which are orphaned and pick them up; and look for those which are frequently marked out of date and consider asking the maintainer if they'd be interested in co-maintainership.
Florian
On 11/09/2021 09.44, Florian Bruhin via aur-general wrote:
Hey Jason,
On Fri, Sep 10, 2021 at 07:19:16PM -0400, Jason Kercher via aur-general wrote:
if anyone has a minute to look at my PKGBUILD, that would be great.
A couple of suggestions:
- Variables which are empty or set to their default values (e.g. pkgver=1.0) aren't needed. I'd recommend only setting those you actually want to set.
For some of the empty arrays, I agree, but I'd leave pkgver= as-is - it just happens to be 1.0 right now, but that will presumably change soon.
- "provides=(libfql.so)" seems odd to me. The "provides" key is used when your package provides a drop-in alternative for another package, but there's no libfql.so package. You can probably just remove that one.
From PKGBUILD(5):
provides (array) [snip] If the provision name appears to be a library (ends with .so), makepkg will try to find the library in the built package and append the correct version. Appending the version yourself disables automatic detection.
This allows you to specify "depends=('foo.so=2')". Not sure if that's actually used anywhere, but many packages specify the provides= anyway.
- Why the "sudo" in "sudo make install"? You don't need root privileges to package something. If you do, then your PKGBUILD is trying to write files outside of $pkgdir, which would be bad.
That is indeed what it's trying to do - OP didn't use DESTDIR with "make install", so it's trying to install to the host system. Slapping a "sudo" in front of it is of course the completely wrong thing to do, and causes anyone building the package outside a chroot to clobber their system.
Xiretza
On Sat, Sep 11, 2021 at 10:22:13AM +0200, Xiretza via aur-general wrote:
On 11/09/2021 09.44, Florian Bruhin via aur-general wrote:
Hey Jason,
On Fri, Sep 10, 2021 at 07:19:16PM -0400, Jason Kercher via aur-general wrote:
if anyone has a minute to look at my PKGBUILD, that would be great.
A couple of suggestions:
- Variables which are empty or set to their default values (e.g. pkgver=1.0) aren't needed. I'd recommend only setting those you actually want to set.
For some of the empty arrays, I agree, but I'd leave pkgver= as-is - it just happens to be 1.0 right now, but that will presumably change soon.
Err, agreed. I meant pkgrel=1.
- "provides=(libfql.so)" seems odd to me. The "provides" key is used when your package provides a drop-in alternative for another package, but there's no libfql.so package. You can probably just remove that one.
From PKGBUILD(5):
provides (array) [snip] If the provision name appears to be a library (ends with .so), makepkg will try to find the library in the built package and append the correct version. Appending the version yourself disables automatic detection.
This allows you to specify "depends=('foo.so=2')". Not sure if that's actually used anywhere, but many packages specify the provides= anyway.
Oh! I've never noticed so far even after some >10 years of using Archlinux, I stand corrected. Thanks for the explanation!
- Why the "sudo" in "sudo make install"? You don't need root privileges to package something. If you do, then your PKGBUILD is trying to write files outside of $pkgdir, which would be bad.
That is indeed what it's trying to do - OP didn't use DESTDIR with "make install", so it's trying to install to the host system. Slapping a "sudo" in front of it is of course the completely wrong thing to do, and causes anyone building the package outside a chroot to clobber their system.
Blindly adding "sudo" when something doesn't work often isn't the right thing to do. Yet it's done way too often... I'm probably guilty of it myself on one occasion or another, though.
Florian
aur-general@lists.archlinux.org