[aur-general] [REVIEW REQUEST] python-viivakoodi

Eli Schwartz eschwartz93 at gmail.com
Wed Nov 30 04:59:45 UTC 2016


On 11/29/2016 08:19 PM, Quentin Bourgeois wrote:
> Ouch, one new try :p

Looks good to me. I'd say it is ready to upload to the AUR.

> Definitely, but its quiet fun to be faced with such problems.

It's also quite fun even when you're loud. ;)

> If you may I propose the following summary in order to assert that
> I am starting to get a bigger picture:
> 
> - setuptools related stuff
> Some project, like viivakoodi, needs setuptools for installation. In
> such case pythonX-setuptools is needed at build-time.
>   * If we provide a split packages both python{,2}-setuptools should
>   be included into makedepends()
>   * If the project use *console_scripts* entry points
>   pythonX-setuptools is needed as the runtime dependencies too. 
> 
> - PKGBUILD/makepkg related stuff
> At built-time makepkg "merge" both makedepends() and depends().
>   * However, if we are building a split package with a depends()
>   inside a package_* function, this depends() will not be watched at
>   built-time. So packager must "copy" the content of package_*
>   depends() into global makedepends() in that particular case.

Yup, that's about it. Predicated on the build needing all runtime
dependencies installed, which is the case for setuptools.

It is worth noting purely for correctness, that the *console_scripts*
spec also has a brother called *gui_scripts*, which is the same thing
but indicates the script/exe should launch a GUI instead of existing in
a terminal. (I guess that has a practical difference on Windows.)

While not referenced here because viivakoodi has none, projects that
have *gui_scripts* display the same behavior -- setuptools is generating
the *entry_points* ==> {console,gui}_scripts instead of using the
user-supplied *scripts* , and since setuptools generates it for you it
embeds itself into the scene. I suppose this is useful for allowing it
to check the *.egg-info/requires.txt at runtime, although distro
packaging theoretically takes care of that for us.

-- 
Eli Schwartz


More information about the aur-general mailing list