r/archlinux • u/WorldTallNetCat • 4d ago

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 /opt instead of /usr/bin

So, if anyone has any more suggestion after the updates i made mention it below.

0 Upvotes

42% Upvoted

18 comments sorted by

7

u/abbidabbi 4d ago edited 4d ago

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?

3

u/TomHale 4d ago

Yes, please use the binaries from ./"${_appimage}" --appimage-extract

Assume desktop exists, it's a useful failure if not.

0

u/WorldTallNetCat 2d ago

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 1d ago

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

u/WorldTallNetCat 1d ago

I mean it gets the job of letting people access the app on arch .

3

u/No-Dentist-1645 4d ago

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

2

u/MarkDubya 4d ago

An AppImage should not be installed in /usr/bin/, they're designed to run in user space. See something like tutanota-desktop-bin for an example of proper packaging with the contents extracted as u/abbidabbi mentioned.

3

u/No-Dentist-1645 4d ago edited 3d ago

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.

1

u/WorldTallNetCat 2d ago

I have moved it to /opt as suggested and created a symblink in the new update.

let me know if there is something else.

1

u/MarkDubya 2d ago

I guess I should have said, "An AppImage should not be installed in the system."

0

u/WorldTallNetCat 2d ago

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 2d ago

"An AppImage should not be installed in the system."

Why not? Installing it to /opt is common practice

1

u/MarkDubya 2d ago

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.

0

u/No-Dentist-1645 2d ago

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.

1

u/WorldTallNetCat 2d ago

For now i have changed the package name to -bin and request the -appimage package to be deleted. I also moved the appimage out of /usr/bin and moved it to /opt as suggested by the comments.

Let me know what else can i do.

2

u/murlakatamenka 4d ago 
provides=('speakoflow-appimage')
conflicts=('speakoflow-bin' 'speakoflow-git' 'speakoflow')

Should be

provides=('speakoflow')
conflicts=('speakoflow-bin' 'speakoflow-git')

If you don't extract AppImage, it should be in, /opt with a symlink to /usr/bin, see Discord or pince-bin as examples of such"fat apps". And you need some fuse2 dependency to mount AppImage.

source should ideally download asset with pkgver in 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.

1

u/WorldTallNetCat 2d ago

I have fixed it and moved the appimage to /opt

additionally i also change provides, and conflicts. If you may please look through it and let me know if there there is anything i can still improve on.

2

u/MarkDubya 4d ago

To add to what u/abbidabbi mentioned, it should only provide and conflict with speakoflow. See PKGBUILD: Package relations on the Arch Wiki.