[aur-general] rfc: pkgbuild for prospect releng-tool
james.d.knight at live.com
Thu Mar 7 02:53:54 UTC 2019
On 2019-03-06 2:03 AM, DJ Lucas (LFS) wrote:
> Python 2/3?
The package type does support either Python variant. When I was first
making the package, I first attempted to build the PKGBUILD file
following the "Python package guidelines" ; however, I felt that it
would be incorrect to label the package with such a prefix. The
guidelines mention that the prefix is either for "[Python] library
modules" or a package that "is strongly coupled to the Python
ecosystem". While the tool is built and uses Python for support, it is
not specifically designed Python-only projects/etc. My choice to have to
use the project's common entry-point/package name felt right to me after
seeing the Bazaar package  doing the same thing. That being said, if
I made an incorrect assumption here, I can make any appropriate change.
In additional to the note being either Python 2 or 3, as mentioned
above, the tool does support either. After moving from a Python-prefixed
package I still had an initial PKGBUILD which would build two types of
packages: releng-tool and releng-tool-27. The idea would be that if a
host only had one variant of Python, releng-tool could still be
installed on the system. Since I am hoping the tool will introduce the
entry-point "releng-tool", I did not want to try to also introduce a
second entry point "releng-tool-27" (picked to avoid conflicts)
primarily since I did not want the Bash completion to hang on
"releng-tool" waiting for either a space or a dash before providing
additional information. Although now thinking about it, my decision was
most likely incorrect. If a user did install only one of the variants,
the completion would handle as "desired". If for some reason both are
installed, the user should have the right to be able to auto-complete to
either. With that in mind, I will most likely be introducing the second
variant as well -- possibly in a fashion such as:
> Use depends here, makedepends implicitly includes depends.
With the above related to possibly introducing the two package types and
a discussion in a related thread indicating I may need
"python-setuptools" as a "makedepends" entry, I will be cleaning up the
listed dependencies. Hopefully it will be correct in my next version.
> If you intend to use a version string and not a specific git commit, then get the versioned tarball from https://github.com/releng-tool/releng-tool/archive/v0.1/releng-tool.tar.gz and provide the sums. Also, since you are the developer, sig? You can add it, as well as other compression formats as part of the release process on GitHub. I think it's add resources, or similar, been a bit.
From my past experience with downloading versioned tarballs from GitHub
is that there is no guarantee that the fetched package will always be
the same hash (useless this is something that has recently changed;
although I cannot seem to find any documentation on this).
I stumbled upon the VCS option and figured it would be a "better"
approach, but I would agree that while Git may help ensure there is no
corruption, it does not guarantee authenticity. I am going to be making
another release soon, which I then could include signed/checksum
packages of the release into GitHub (as you have mentioned). This
followed by moving away from the VCS type to an archive and adding the
appropriate sha512 hash can be done (assuming this is the preferred
> Personal preference, and likely not very useful here, but use -v for install commands, it could save you some time if something breaks in the future.
I will add the tweak. Something always breaks in the future.
Thanks for the suggestions.
More information about the aur-general