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=packag... [3]: https://wiki.archlinux.org/index.php/VCS_package_guidelines