QA for intentionally unpackaged files

QA for intentionally unpackaged files

[Junqian Gordon Xu]

Now there is no way to distinguish if the following is intensional by 
the package maintainer or an oversight without taking a closer look at 
the contents

NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libpython2.4.so
NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
NOTE:   /usr/share/man/man1/python.1
NOTE:   /usr/bin/python2.4
NOTE:   /usr/bin/smtpd.py
NOTE:   /usr/bin/.debug/python

Maybe we should have something in insane.bb to take care of the 
intentionally unpackaged crusts. So we can do something like the 
following in a bb file to intensionally leave out some garbage unpackaged:

UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why 
not package/ship it

so during do_package or package_QA, it would show as

NOTE: the following files were installed but not shipped in any package:
NOTE:   /usr/lib/libpython2.4.so   UNSHIPPED #reason why not 
packaged/ship it
NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
NOTE:   /usr/share/man/man1/python.1
NOTE:   /usr/bin/python2.4
NOTE:   /usr/bin/smtpd.py  UNSHIPPED #reason why not packaged/ship it
NOTE:   /usr/bin/.debug/python

Is SUNK a better word than UNSHIPPED?

Gordon

Re: QA for intentionally unpackaged files

[Paul Sokolovsky]

Hello Junqian,

Wednesday, May 9, 2007, 5:25:00 AM, you wrote:

> Now there is no way to distinguish if the following is intensional by 
> the package maintainer or an oversight without taking a closer look at
> the contents

        So, maybe "closer look" is indeed a solution here?

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /usr/lib/libpython2.4.so
> NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
> NOTE:   /usr/share/man/man1/python.1
> NOTE:   /usr/bin/python2.4
> NOTE:   /usr/bin/smtpd.py
> NOTE:   /usr/bin/.debug/python

> Maybe we should have something in insane.bb to take care of the 
> intentionally unpackaged crusts. So we can do something like the 
> following in a bb file to intensionally leave out some garbage unpackaged:

> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
> not package/ship it

        Who exactly will go over all recipes and add such lines?

> so during do_package or package_QA, it would show as

> NOTE: the following files were installed but not shipped in any package:
> NOTE:   /usr/lib/libpython2.4.so   UNSHIPPED #reason why not 
> packaged/ship it

        No, thanks, it likely shouldn't dump them at all then.

> NOTE:   /usr/lib/.debug/libpython2.4.so.1.0
> NOTE:   /usr/share/man/man1/python.1
> NOTE:   /usr/bin/python2.4
> NOTE:   /usr/bin/smtpd.py  UNSHIPPED #reason why not packaged/ship it
> NOTE:   /usr/bin/.debug/python

> Is SUNK a better word than UNSHIPPED?

        No.

> Gordon


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: QA for intentionally unpackaged files

[Michael Krelin]

> 
>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>> not package/ship it
> 
>         Who exactly will go over all recipes and add such lines?

I take it the proposal was that package maintainers should take care of
it. Indeed, it would be better if intentionally unpackaged files invoked
no QA notice. But I think the solution is either not install them or rm
them after installation, depending on installation procedure nature.


Love,
H

Re: QA for intentionally unpackaged files

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Krelin schreef:
>>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>>> not package/ship it
>>         Who exactly will go over all recipes and add such lines?
> 
> I take it the proposal was that package maintainers should take care of
> it. Indeed, it would be better if intentionally unpackaged files invoked
> no QA notice. But I think the solution is either not install them or rm
> them after installation, depending on installation procedure nature.

Or we could patch package.bbclass[1] to do:

PACKAGES += "${PN}-leftovers"
FILES_${PN}-leftovers = "/"

I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
by looking at deploy.

regards,

Koen

[1] this wouldn't work in bitbake.conf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQaWiMkyGM64RGpERAuTXAKCD+n1gXwbL7dyqru7UySv82J/CXQCgmTUM
7dYtDM79sAYQSnyDtwKmcfM=
=hEE+
-----END PGP SIGNATURE-----

Re: QA for intentionally unpackaged files

[Junqian Gordon Xu]

Koen Kooi wrote:
> Or we could patch package.bbclass[1] to do:
>
> PACKAGES += "${PN}-leftovers"
> FILES_${PN}-leftovers = "/"
>
> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
> by looking at deploy.

Again, how do you know which one is "intentionally" left-over vs. which 
one is not?

Gordon

Re: QA for intentionally unpackaged files

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junqian Gordon Xu schreef:
> Koen Kooi wrote:
>> Or we could patch package.bbclass[1] to do:
>>
>> PACKAGES += "${PN}-leftovers"
>> FILES_${PN}-leftovers = "/"
>>
>> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
>> by looking at deploy.
> 
> Again, how do you know which one is "intentionally" left-over vs. which 
> one is not?

I can't think of a valid reason for not packaging files.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGQa/LMkyGM64RGpERAjF7AJkBFh9SE86gjvybHZ7PRwc0+Cl2qwCcDV1h
tStk9ih9NSv558uCHvxA4G8=
=caUf
-----END PGP SIGNATURE-----

Re: QA for intentionally unpackaged files

[Paul Sokolovsky]

Hello Koen,

Wednesday, May 9, 2007, 2:26:03 PM, you wrote:


> Junqian Gordon Xu schreef:
>> Koen Kooi wrote:
>>> Or we could patch package.bbclass[1] to do:
>>>
>>> PACKAGES += "${PN}-leftovers"
>>> FILES_${PN}-leftovers = "/"
>>>
>>> I'm not sure if that works, but if it does, we would be able to spot leftovers more easily
>>> by looking at deploy.
>> 
>> Again, how do you know which one is "intentionally" left-over vs. which 
>> one is not?

> I can't think of a valid reason for not packaging files.

        busybox doesn't package symlinks, as update-alternative
recreates them on install.


        But I agree that catch-all package is better idea than another
adhoc var. Except that we probably should add ${PN}-unshipped and
${PN}-leftovers to distinguish those intentional vs missed cases.

> regards,

> Koen

-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: QA for intentionally unpackaged files

[Michael Krelin]

> 
>         But I agree that catch-all package is better idea than another
> adhoc var. Except that we probably should add ${PN}-unshipped and
> ${PN}-leftovers to distinguish those intentional vs missed cases.
> 

How would any catch-all solution actually differ from disabling QA
notice? Except for that you'd be able to install these leftovers.

Love,
H

Re: QA for intentionally unpackaged files

[Michael Krelin]

> Michael Krelin schreef:
>>>> UNSHIPPED = "${libdir}/libpython2.4.so ${bindir}/smtpd.py"  #reason why
>>>> not package/ship it
>>>         Who exactly will go over all recipes and add such lines?
>> I take it the proposal was that package maintainers should take care of
>> it. Indeed, it would be better if intentionally unpackaged files invoked
>> no QA notice. But I think the solution is either not install them or rm
>> them after installation, depending on installation procedure nature.
> 
> Or we could patch package.bbclass[1] to do:
> 
> PACKAGES += "${PN}-leftovers"
> FILES_${PN}-leftovers = "/"

I'd rather propose, indeed, packaging the intentional leftovers into a
-leftovers package manually on each package that wants leftovers. But as
you pointed out that there are no valid reasons for files to be
unpackaged, I'm sure it's possible to come up with more meaningful name
for -leftovers package in each particular case. And before files are
packaged QA notice stays QA notice, because it *is* QA issue ;-)


Love,
H

Re: QA for intentionally unpackaged files

[Junqian Gordon Xu]

Paul Sokolovsky wrote:
>
>         So, maybe "closer look" is indeed a solution here?
>
>   
>         Who exactly will go over all recipes and add such lines?
>
>   
>
>         No, thanks, it likely shouldn't dump them at all then.

I take it as to find an easy and uncumbersome way to take care of this. 
I don't think doing nothing at all is a good solution.

Gordon