[oe] [PATCH] libfribidi-0.10.4: update recipe, fix packaging
Andreas Oberritter
obi at opendreambox.org
Mon Oct 18 11:41:09 UTC 2010
On 10/18/2010 12:48 PM, Koen Kooi wrote:
> On 18-10-10 12:21, Andreas Oberritter wrote:
>> On 10/18/2010 09:22 AM, Koen Kooi wrote:
>>> On 18-10-10 00:15, Andreas Oberritter wrote:
>>>> * added LICENSE
>>>> * removed configure patch
>>>> * use lib_package and binconfig to package all installed files
>>>
>>> What's the upgrade path? I assume package names have changes due to this.
>
>> I guess my patch description wasn't clear enough.
>
>> The previously unpackaged files ${bindir}/fribidi and
>> ${bindir}/fribidi-config are now packaged into libfribidi-bin and
>> libfribidi-dev, respectively.
>
>> The only file which moved to a different package is libfribidi.a, from
>> libfribidi-static to libfribidi-dev.
>
> Well, .a files are supposed to go into -static, not into -dev.
>
>> Does this change require special treatment for upgrades?
>
> Every time you change packaging you need to make sure upgrade paths are
> intact. Especially with libraries.
OK, I understand.
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?
Regards,
Andreas
More information about the Openembedded-devel
mailing list