[aur-general] rfc: pkgbuild for prospect releng-tool

[James Knight]

On 2019-03-06 2:03 AM, DJ Lucas (LFS) wrote:
>> pkgname=releng-tool
> 
> 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" [1]; 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 [2] 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:

     pkgbase=releng-tool
     pkgname=(releng-tool releng-tool27)

> 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 
approach).

> 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.

[1]: https://wiki.archlinux.org/index.php/Python_package_guidelines
[2]: 
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/bzr
[3]: https://wiki.archlinux.org/index.php/VCS_package_guidelines