[gentoo-dev] repoman warning on python data_files

[gentoo-dev] repoman warning on python data_files

[yac]

Hi

I have just noticed that if package is using relative paths in::

    setup.py data_files = ...

Then the files are installed right into /usr in case of CPython (The
exact dest is determined by sys.prefix)

So, I'm thinking it could be worthwhile to add a warning to repoman if
package is using this method as I can imagine this can be easily
overlooked when creating a new package or mostly when bumping one.

Re: [gentoo-dev] repoman warning on python data_files

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

Dnia 2013-06-09, o godz. 06:13:32
yac <yac@gentoo.org> napisał(a):

> Hi
> 
> I have just noticed that if package is using relative paths in::
> 
>     setup.py data_files = ...
> 
> Then the files are installed right into /usr in case of CPython (The
> exact dest is determined by sys.prefix)
> 
> So, I'm thinking it could be worthwhile to add a warning to repoman if
> package is using this method as I can imagine this can be easily
> overlooked when creating a new package or mostly when bumping one.

Err, I feel like I'm missing the point here.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] repoman warning on python data_files

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]

On Sun, 9 Jun 2013 06:13:32 +0200
yac <yac@gentoo.org> wrote:

> I have just noticed that if package is using relative paths in::
> 
>     setup.py data_files = ...
> 
> Then the files are installed right into /usr in case of CPython (The
> exact dest is determined by sys.prefix)
> 
> So, I'm thinking it could be worthwhile to add a warning to repoman if
> package is using this method as I can imagine this can be easily
> overlooked when creating a new package or mostly when bumping one.

repoman currently doesn't run any ebuild phases as far as I am aware.
For it to be able to warn, it has to run at least the unpack phase;
running the unpack phase of each ebuild in the directory is costly.

For this to actually properly work, it would need to run all phases;
you don't get false positives and it then can actually check the image.

What good use has this? Not much. Maintainers should check the image
themselves; just to name a few this includes 1) unbundling libraries, 2)
checking if everything is present, 3) checking if things are missing
(important run time files, doc, examples and sometimes even source), 4)
checking that needed libraries (eg. readelf) are listed in DEPEND and
in your case 5) checking if things are installed to the correct paths.

Just one check won't make up for the others, _you_ have to check them.

Although; since this is Python, maybe the Python eclasses can do that?
That way you wouldn't have to introduce slower processing in repoman;
since eclasses can do these QA checks at the right moment, during merge.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]