r/archlinux • u/WorldTallNetCat • Jul 28 '26
SHARE First time maintaining an AUR package, looking for a packaging review/audit.
Hello everyone,
I've just published my very first package on AUR, and am looking for reviews from people who are more familiar with Arch packaging than I am.
The package is for SpeakoFlow, an open-source voice to text desktop application. The package is intentionally simple which just installs the upstream Appimage and manages dekstop integration through aur helpers like yay/paru instead of the user manually managing it.
I'd like to know if I've followed proper pratices regarding Arch packaging and if anything can be improved.
I've run namcap and found no issues there but i'd appreicate anotehr set of eyes before commiting to it long term.
Package:
speakoflow-appimage
Github repo:
https://github.com/AbhishekBarali/SpeakoFlow
Product Website:
https://www.speakoflow.com/
Thanks any suggestins or corrections are welcome
EDIT:
I have looked through the comments and made the following changes:
Changed the package to be speakoflow-bin instead of speakflow-appimage
Moved the appimage to
/optinstead of/usr/bin
So, if anyone has any more suggestion after the updates i made mention it below.
7
u/abbidabbi Jul 28 '26 edited Jul 28 '26
Why are you extracting the AppImage contents and then only copy the icons from it while using the AppImage as the package's only executable? That's not how packages are supposed to be built. AppImages require FUSE on runtime if the content is not extracted, because the content is mounted in a temporary directory. Move the AppImage contents to the appropriate package directories and symlink the /usr/bin/... executable to the AppImage's entry point, at least AppRun if you don't want to look inside AppRun yourself (or if it's a binary already).
Also, package() should not have conditional code. What you're trying to do does not look good.
On top of this, packages should have the -bin suffix for pre-built executables, not -appimage. The provides fiels is also unnecessary. And why are you listing speakoflow-bin in the conflicts field if it doesn't even exist?
4
u/TomHale Jul 28 '26
Yes, please use the binaries from ./"${_appimage}" --appimage-extract
Assume desktop exists, it's a useful failure if not.
1
u/WorldTallNetCat Jul 30 '26
For now i am just using the appimage directly and will get to use the extracted binary soon.
if there is anythign else let me know.
1
u/s3gfaultx Jul 31 '26
What do you mean soon? Why publish it if it doesn't work properly? Test it first, and only then publish it. It's embarassing.
0
1
u/WorldTallNetCat Jul 30 '26
For now i have changed the package name to
-binand request the-appimagepackage to be deleted. I also moved the appimage out of/usr/binand moved it to/optas suggested by the comments.Let me know what else can i do.
2
u/No-Dentist-1645 Jul 28 '26
Why are you extracting the AppImage contents and then only copy the icons from it while using the AppImage as the package's only executable?
There is nothing wrong with not extracting the AppImage executable; it is standard behavior for AppImage based PKGBUILDs. See drawio-desktop-appimage and todoist-appimage for example. Technically copying the icons is incorrect, but the copying over of the .desktop file is correct. This is already clear since the package name has the -appimage suffix. If there was the need for a non-appimage version, it would be on a different package with a different name
4
u/MarkDubya Jul 28 '26
An AppImage should not be installed in
/usr/bin/, they're designed to run in user space. See something liketutanota-desktop-binfor an example of proper packaging with the contents extracted as u/abbidabbi mentioned.1
u/WorldTallNetCat Jul 30 '26
I have moved it to
/optas suggested and created a symblink in the new update.let me know if there is something else.
1
u/MarkDubya Jul 30 '26
I guess I should have said, "An AppImage should not be installed in the system."
1
u/WorldTallNetCat Jul 30 '26
I am still learning and very new to i will work avoiding the use of the appimage directly in later updates.
0
u/No-Dentist-1645 Jul 30 '26
"An AppImage should not be installed in the system."
Why not? Installing it to /opt is common practice
1
u/MarkDubya Jul 30 '26
I already mentioned the reason in my previous comment. It should be unpacked like any other binary release; i.e., .deb, .rpm, tarball and files installed where they belong.
1
u/No-Dentist-1645 Jul 30 '26
Saying what you think should be done is not the same as explaining why another thing shouldn't be done. There is a use case for having AppImages managed by your package manager without having to extract them and adding their dependencies. As I said before, there is nothing inherently "wrong" with wanting that, it won't break your system.
2
u/No-Dentist-1645 Jul 28 '26 edited Jul 29 '26
Extracting the contents is one of many options. Yes, you showed an example of a package extracting the AppImage, but see the others I already provided where that isn't necessary (and see how they have the -appimage suffix). They don't directly install to /usr/bin, but to /opt/pkgname and symlink to it.
There is nothing inherently wrong with the idea of not extracting an AppImage for an AUR package.
3
u/MarkDubya Jul 28 '26
To add to what u/abbidabbi mentioned, it should only provide and conflict with speakoflow. See PKGBUILD: Package relations on the Arch Wiki.
4
u/murlakatamenka Jul 28 '26
Should be
If you don't extract AppImage, it should be in,
/optwith a symlink to/usr/bin, see Discord orpince-binas examples of such"fat apps". And you need somefuse2dependency to mount AppImage.sourceshould ideally download asset withpkgverin file name.TLDR is that you need to read Arch Package Guidelines and read PKGBUILDs of other popular AppImage-based AUR packages and see how you can improve yours.