Hello, I want to submit five packages to the AUR for the Psono Password Manager. It's open source and I got permission from the developer to do so with the disclaimer that they are not officially supported. Three of these packages require a python virtual environment (due to the extensive list of python dependencies that are not available in the Arch Linux repositories) and the way I initially approached this was to use the post_install() function in the install script. Here's the PKGBUILD review link on the forums: https://bbs.archlinux.org/viewtopic.php?id=312591 With the advice of Lone_Wolf and twelveeighty I moved the venv creation to the build() function of the PKGBUILD. Psono is only available in a docker image format so I created a custom dlagent to download the docker image, extract the software I need for the package, tarball it and use the tarball as a source file for hash verification. Using a constant mtime value while creating the tarball makes sure the hash stays the same with the same files if they aren't changed upstream. My question for the AUR moderators and package maintainers is as follows: the python venv is created when building the package and is shipped with the package. Is this acceptable for the AUR? What's your opinion? Am I allowed to submit these packages like they are? I also attached one of the three packages' source so you can test building it yourself. Currently it doesn't have licenses set up yet. It's the enterprise edition of Psono's server software. There's also a community edition available that's free that I also intend to submit if allowed. The hashes should be up to date with the enterprise edition. Let me know what you think. Kind regards, 7thCore
On 2026-03-20 11:41, 7thCore wrote:
With the advice of Lone_Wolf and twelveeighty I moved the venv creation to the build() function of the PKGBUILD. Psono is only available in a docker image format so I created a custom dlagent to download the docker image, extract the software I need for the package, tarball it and use the tarball as a source file for hash verification. Using a constant mtime value while creating the tarball makes sure the hash stays the same with the same files if they aren't changed upstream.
the source is available on gitlab. would it make more sense to build from source, instead of extracting from a docker image? you can more easily verify this way that the source hasn't been tampered with. https://gitlab.com/esaqa/psono/psono-server Mark
That is true for the community edition. However the enterprise edition of the software is not available on gitlab. V pet., 20. mar. 2026, 20:00 je oseba Mark Hegreberg <mark@archlinux.org> napisala:
On 2026-03-20 11:41, 7thCore wrote:
With the advice of Lone_Wolf and twelveeighty I moved the venv creation to the build() function of the PKGBUILD. Psono is only available in a docker image format so I created a custom dlagent to download the docker image, extract the software I need for the package, tarball it and use the tarball as a source file for hash verification. Using a constant mtime value while creating the tarball makes sure the hash stays the same with the same files if they aren't changed upstream.
the source is available on gitlab. would it make more sense to build from source, instead of extracting from a docker image? you can more easily verify this way that the source hasn't been tampered with.
https://gitlab.com/esaqa/psono/psono-server
Mark
due to the extensive list of python dependencies that are not available in the Arch Linux repositories
Why is packaging the dependencies not an option? Martin On Fri, Mar 20, 2026 at 8:04 PM 7th Core <the7thcore@gmail.com> wrote:
That is true for the community edition. However the enterprise edition of the software is not available on gitlab.
V pet., 20. mar. 2026, 20:00 je oseba Mark Hegreberg <mark@archlinux.org> napisala:
On 2026-03-20 11:41, 7thCore wrote:
With the advice of Lone_Wolf and twelveeighty I moved the venv creation to the build() function of the PKGBUILD. Psono is only available in a docker image format so I created a custom dlagent to download the docker image, extract the software I need for the package, tarball it and use the tarball as a source file for hash verification. Using a constant mtime value while creating the tarball makes sure the hash stays the same with the same files if they aren't changed upstream.
the source is available on gitlab. would it make more sense to build from source, instead of extracting from a docker image? you can more easily verify this way that the source hasn't been tampered with.
https://gitlab.com/esaqa/psono/psono-server
Mark
Requirements versions. Dependsncies in the requirements.txt are version specific. The software doesn't always use the latest version. You can look at the requirements.txt in the tarball I provided and compare them on pypi.org V pet., 20. mar. 2026, 23:32 je oseba Martin Rys <spleefer90@gmail.com> napisala:
due to the extensive list of python dependencies that are not available in the Arch Linux repositories
Why is packaging the dependencies not an option?
Martin
On Fri, Mar 20, 2026 at 8:04 PM 7th Core <the7thcore@gmail.com> wrote:
That is true for the community edition. However the enterprise edition
of the software is not available on gitlab.
V pet., 20. mar. 2026, 20:00 je oseba Mark Hegreberg <mark@archlinux.org>
napisala:
On 2026-03-20 11:41, 7thCore wrote:
With the advice of Lone_Wolf and twelveeighty I moved the venv creation to the build() function of the PKGBUILD. Psono is only available in a docker image format so I created a custom dlagent to download the docker image, extract the software I need for the package, tarball it and use the tarball as a source file for hash verification. Using a constant mtime value while creating the tarball makes sure the hash stays the same with the same files if they aren't changed upstream.
the source is available on gitlab. would it make more sense to build from source, instead of extracting from a docker image? you can more easily verify this way that the source hasn't been tampered with.
https://gitlab.com/esaqa/psono/psono-server
Mark
Hi, On 21.03.26 6:44 AM, 7th Core wrote:
Requirements versions. Dependsncies in the requirements.txt are version specific. The software doesn't always use the latest version.
But that goes for most upstream projects? [1] In practice, building a distro package often means that it’s your responsibility to gloss over this kind of mismatch, graft the thing onto whatever your distro happens to carry, and ideally contribute your (forward-porting) patches upstream. Regards Claudia [1] Except if the ecosystem relies on static linking (e.g., Rust) or its batteries are so weak that the average dependency tree grows too massive to handle (NPM).
Understood. I'll shelve this for now. I'm honestly not that good regarding python coding and my current job is not anything regarding software development so I'll keep this to myself then. Thank you all for your input. V sob., 21. mar. 2026, 13:15 je oseba Claudia Pellegrino <gpg@cpellegrino.de> napisala:
Hi,
On 21.03.26 6:44 AM, 7th Core wrote:
Requirements versions. Dependsncies in the requirements.txt are version specific. The software doesn't always use the latest version.
But that goes for most upstream projects? [1]
In practice, building a distro package often means that it’s your responsibility to gloss over this kind of mismatch, graft the thing onto whatever your distro happens to carry, and ideally contribute your (forward-porting) patches upstream.
Regards Claudia
[1] Except if the ecosystem relies on static linking (e.g., Rust) or its batteries are so weak that the average dependency tree grows too massive to handle (NPM).
participants (5)
-
7th Core
-
7thCore
-
Claudia Pellegrino
-
Mark Hegreberg
-
Martin Rys