[aur-general] AUR Best Practice for New Package Upload

stef stef_204 at yahoo.com
Tue Sep 16 10:31:13 UTC 2014

On Sat, 9/6/14, Johannes Löthberg <johannes at kyriasis.com> wrote:

 Subject: Re: [aur-general] AUR Best Practice for New Package Upload
 To: "Discussion about the Arch User Repository (AUR)" <aur-general at archlinux.org>
 Date: Saturday, September 6, 2014, 1:03 PM
 On 06
 Sep 2014, at 12:06, stef <stef_204 at yahoo.com>
 > 1) the main script which is CLI
 (available for python2 and/or python3)
 2) a GTK+ GUI (optional) for python2
 3)  the GTK+ GUI (optional) for python3
 > I use the GTK+GUI for
 python3 on my box but perhaps some users might want (or have
 > use python2.
 > Question 1):
 > The program is small
 (approx 250kb only) and my tendency would be to just do the
 > package with all 3 components which
 users will then use as they see fit, CLI only or
 > GUI, etc.  This would allow me to
 maintain only one package for this program.
 >Is only one package OK
 with the AUR community?
 shouldn’t mix python2 and 3. Make it a split package.
 > Question 2) I just
 basically downloaded the source tarball, extracted it to
 /opt and
 > am running it from there.
 > My idea is to achieve
 the same with PKGBUILD, following proper protocol, etc.
 > Is “installing”
 (extracting dir structure) to /opt a problem?
 Don’t do that, it’s very
 ewwy. Read up on how and where python packages are normally
 Or actually, read up on setuptools
 and write a setup.py that you can use in the



Sorry for not snipping the above quotes, but I wanted to leave all of the relevant info which might help.

This is the program <https://github.com/jdleicher/MassHash/>
MassHash: A set of file hashing tools.

To be clear, this program, for which I am trying to build my first AUR PKGBUILD (bear with me please, still learning) is NOT a python package or library.

So perhaps a setup.py may not necessarily be needed or relevant in this case. (I could be wrong.)

1. The program is not "expanding/extending" the Python Language itself.  In other words it is not installing TO or writing code FOR Python, but USING the language for an end user application.  Again, it is a PROGRAM, not a "python package".

2. Both the CLI and GUI are programs and not libraries.  It might make sense to install a python library/package to the language installation itself so that other scripts can easily "import" said library/package into the code.  But possibly not in this case.

Right now, personally, on my box, I have the package as so (I just downloaded it since it is self-contained, there is nothing to build; and am just running it from there):


*The program is self-contained.*

In each of /opt/MassHash/python2/ and /opt/MassHash/python3/ there are 2 executables: masshash for the CLI and masshash-launcher to launch the program with the GTK+ GUI.

So looking at <https://wiki.archlinux.org/index.php/Python_Package_Guidelines> I am not sure this applies here.

And looking at <https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Directories> 
one idea would be to install as such:


Then the PKGBUILD script creates another script or symlink which is placed in /usr/bin

Would either /opt or /usr/share as above work or do you guys confirm that, according to AUR packaging standards it should have a setup.py ?
(Johannes has already told me not to use /opt but I had not given the full data previously. Johannes, based on the additional info given here, feel free to confirm your earlier recommendation; or change it, as the case may be.)

Guys, please also, let me know if the AUR forum might be better suited for this discussion and if so, I will move it there.

Thanks a lot for your feedback and patience.

More information about the aur-general mailing list