[aur-general] AUR Best Practice for New Package Upload
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
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
> 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