Re: [PATCH] libfribidi-0.10.4: update recipe, fix packaging

[Andreas Oberritter <obi@opendreambox.org>]

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