From: Andreas Oberritter <obi@opendreambox.org>
To: openembedded-devel@lists.openembedded.org
Subject: [RFC] update lib_package.bbclass
Date: Tue, 19 Oct 2010 20:01:49 +0200 [thread overview]
Message-ID: <4CBDDD0D.1080303@opendreambox.org> (raw)
In-Reply-To: <4CBC3255.3040007@opendreambox.org>
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
next prev parent reply other threads:[~2010-10-19 18:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-17 22:15 [PATCH] libfribidi-0.10.4: update recipe, fix packaging Andreas Oberritter
2010-10-18 7:22 ` Koen Kooi
2010-10-18 10:21 ` Andreas Oberritter
2010-10-18 10:48 ` Koen Kooi
2010-10-18 11:41 ` Andreas Oberritter
2010-10-19 18:01 ` Andreas Oberritter [this message]
2010-10-20 7:47 ` [RFC] update lib_package.bbclass Koen Kooi
2010-10-20 10:50 ` Andreas Oberritter
2010-10-25 14:20 ` [PATCH] lib_package.bbclass: fix packaging of static libs, inherit binconfig Andreas Oberritter
2010-11-13 16:28 ` Andreas Oberritter
2010-11-13 19:12 ` Tom Rini
2010-11-14 23:49 ` Andreas Oberritter
2010-11-15 15:07 ` Tom Rini
2010-11-15 15:46 ` Andreas Oberritter
2010-11-15 18:11 ` Tom Rini
2010-11-16 11:52 ` Andreas Oberritter
2010-11-16 16:51 ` [PATCH] libfribidi-0.10.4: update recipe, fix packaging Andreas Oberritter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CBDDD0D.1080303@opendreambox.org \
--to=obi@opendreambox.org \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox