[oe] [RFC] update lib_package.bbclass

[Andreas Oberritter]

On 10/18/2010 01:41 PM, Andreas Oberritter wrote:
> On 10/18/2010 12:48 PM, Koen Kooi wrote:
>>
>> Well, .a files are supposed to go into -static, not into -dev.
>>

[...]

> The problem was that I trusted lib_package to do the right thing. So the
> real fix would be to add a -static package to lib_package.bbclass and to
> add RDEPENDS_${PN}-static += "${PN}-dev" somewhere, because static libs
> don't make much sense without develompent headers, right?
> 
> Of course, this would create a different problem with upgrades, but I
> would suspect that the number of users of static libraries on their
> target machines is relatively small and, because a disappearing static
> library doesn't create runtime problems, the installation of a new
> -static package wouldn't impose a huge burden to the user.
> 
> In case this solution was accepted: What's the policy for changing files
> like lib_package.bbclass, in order to trigger an update of all relevant
> packages? To bump every single PR?

I looked deeper into lib_package.bbclass and its history and I saw that
it wasn't updated very often during the last years. It still uses
hardcoded paths and doesn't include some files which would get packaged
without lib_package.bbclass.

What lib_package.bbclass does now, compared to the defaults from
bitbake.conf:

1.) It adds ${libdir}/*.a and /lib/*.a to FILES_${PN}-dev.

2.) It adds ${bindir}/*-config to FILES_${PN}-dev.

3.) It creates an additional package ${PN}-bin, which contains all other
executables: ${bindir}/* ${sbindir}/* /bin/* /sbin/*

4.) It doesn't package any of the following:
            ${datadir}/pixmaps ${datadir}/applications \
            ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
            ${libdir}/bonobo/servers

In f624db1d3c7de3fcb3a9e76d388a8f9f8fedcf5c, Koen introduced
${PN}-static packages, but lib_package.bbclass has not been updated
since then, which was one year ago.

Although it packages ${bindir}/*-config into FILES_${PN}-dev, it does
not include the required mangling applied by binconfig.bbclass. I think
that's wrong and just causes unnecessary confusion. IMO, lib_package
should either inherit binconfig or not, but leave FILES_${PN}-dev
untouched in any case.

Leaving FILES_${PN}-dev untouched would also allow lib_package to
automatically inherit some updates from bitbake.conf and to create
non-empty ${PN}-static packages.

I don't know whether #4 should be changed or whether those directories
were left out on purpose.

So, my current proposal looks like this:

-
inherit binconfig	# ... or not

PACKAGES += "${PN}-bin"

FILES_${PN} = "${libexecdir}/* ${libdir}/lib*${SOLIBS} \
            ${sysconfdir} ${sharedstatedir} ${localstatedir} \
            ${base_libdir}/*${SOLIBS} \
            ${datadir}/${PN} ${libdir}/${PN}/*"

FILES_${PN}-bin = "${bindir}/* ${sbindir}/* \
                ${base_bindir}/* ${base_sbindir}/*"
-

Any opinions?

Regards,
Andreas