On 17-01-23 22:53:35, Eli Schwartz via aur-general wrote:
On 01/23/2017 08:42 PM, Quentin Bourgeois wrote:
Thus, I decide to have a look at the PKGBUILD and suggest some modifications I guess the maintainer will be glad to merge any proposal, but did the community see any thing more to change ? Basically I made use a lot more of its internal variable __pkgname, define python{,2}-setuptools as makedepends and add the license file to the package.
Right, so comment on the AUR that the dependencies are not installed. This is a simple, *standard* fix, and as Justin said, asking for feedback here is a bit... odd. Asking for guidance writing your own PKGBUILDs is one thing (and serves, most of all, to help users learn how to do it properly themeselves), asking us to pick apart selected AUR packages that you happen to use is another thing entirely.
Also, nitpicking over the *extent* of others' use of templating variables like _pkgname is classless, moreso when your own (over)use of __license_filename is a wasteful overreaction.
In fact I was included my previously mail to the mailing as part as my learning experience. My thought was to I don't forget anything I was not relying on the community to make my proposal applied. (Note that using external git was not to takeover or whatsoever the package but just a way to sharing my ideas). Anyway, thanks Eli for opening a new request on the project page.
In another way I don't really understand the rm on the bin directory? The problem I saw is that only installing python2-intelhex wont allow the use of the provided scripts[2]. However, I conducted small tests and they seems to works even with python2. So my guess is to create an other AUR PKGBUILD that will perform pretty the same things but only packaging the provided scripts, let call this package python-intelhex-scripts. Then, one need to enforce a dependencies of python{,2}-intelhex with python-intelhex-script at the same upstream release version.
Absolutely not, this package is doing it the standard and recommended way. And splitting the scripts would not achieve your goal anyway, since the version of python is hardcoded in the shebang -- hence why you yourself explicitly depended on "python", which is not provided by "python2" under any circumstances!
But if you were to split them out, they should've been a third split package in the same PKGBUILD.
Duly noted, I keep this technique for posterity.
-- Eli Schwartz