[oe] testing branch 2010-10-29

[Frans Meulenbroeks]

2010/11/1 Martin Jansa <martin.jansa at gmail.com>:
> On Mon, Nov 01, 2010 at 08:49:32AM +0100, Frans Meulenbroeks wrote:

>>
>> (btw: a good place would probably be [3] and yeah, I am aware of the
>> debian renaming [4], but I am also aware of [5] which as an example
>> says:
>> FILES_${PN} = "\
>>     ${bindir}/* \
>>     ${sbindir}/* \
>>     ${libexecdir}/* \
>>     ${libdir}/lib*.so.* \
>>     .....
>> which was exactly what was in the original commit [6]:
>> +FILES_${PN} = "${libdir}/lib${PN}${SOLIB}"
>
> It's OK, but much better if you also PR bump packages depending on it.
> Because as long as "${bindir}/*" was included in FILES_${PN}, debian
> naming didin't happen (because of multiple binaries in 1 package), the
> same happens when you have multiple libraries in 1 package without
> LEAD_SONAME defined.

Which (at least to me) is highly confusing. I did not expect that
adding/removing things from FILES_${PN} would change the lib renaming.
This seems highly counter-intuitive to me.

Actually I'mkinda  flabbergasted when renaming does and when it does not happen.
That is why I feel some doc is a good plan.

The same holds with the LEAD_SONAME and e.g. the GNU_HASH errors/warnings.
There are all quite common. It would be a good plan to have a page
somewhere describing the meaning of these messages and what to do with
them.
>
> So moving binaries to new FILES_${PN}-utils is probably good move, but
> as side effects it renames libcdio to libcdio5. And because already
> built packages have libcdio instead of libcdio5 in it's runtime depends,
> those needs to be rebuilt (to pick libcdio5 as libcdio.so provider)
>
> Not sure how to check all recipes depending on it (I don't trust DEPENDS
> as some packages are voluntary linked to libcdio just because autotools
> found it). So usually I notice it only when image build fails (opkg
> complaining about missing packages), but that works only for packages
> included in built image :/. And when I notice it, I usually do something
> like:
> find deploy/ipk/ -name Packages -exec grep -B 3 libcdio {} \;
> to see where wrong Depends is and then PR bump those (which still fixes
> only those recipes I'm building as part of some image or ie
> task-shr-feed)

You might want to extend your grep to DEPENDS lines.
Then again this is not trivial if DEPENDS is split over multiple lines
and the package same is something that occurs lots of times outside
the depends var.

In the case where you encounter a depends issue, I hope you also fix
DEPENDS (but actually I'm pretty sure you will :-) )
>
> sometimes it gets even worse, like in this case:
> http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=5fa427d06922297496fcf5ebd6c0a6a5c2adac46
> when edbus.ipk gets empty after moving all libs to separate packages, so
> it won't get upgrade on target and creates conflicts between old package
> containing ie libehal.so.* and new edbus-ehal.ipk providing the same lib
> in newer version.

Upgrading is sometimes a pita.

>
> Feel free to update wiki if you found this explanation (or at least some
> part of it :)) understandable.
>

See above.
The fact is that I am fairly time-constrained next few days. Came back
from elc/oedem last sun, have to leave for another trip upcoming sat
morning.

Have fun! Frans