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 >
signature.asc
Description: PGP signature