RFC: More granular libraries packaging

RFC: More granular libraries packaging

[Marcin Juszkiewicz]

One of our strong points is granular packaging. We have extra packages for 
locales, documentation, development stuff etc. But we can improve it a bit 
more.

Many packages has multiple libraries in package. Not everytime it is 
useful - for example libusb had dependency on libstdc++ just because it 
had libusbpp in same package as libusb.

My proposition is - let split each library to separate package. This will 
enlarge feeds (so ipkg will get hurt more ;( but in some situations can 
give us smaller rootfs.

Probably best solution to get this done will be some extra code in 
package_ipk.bbclass.

Example of package to 'fix' is obexftp:

NOTE: Multiple libraries (libbfb.so.0, libcobexbfb.so.0, libcobexpe.so.0, 
libobexftp.so.0) found and LEAD_SONAME not defined
Packaged contents of obexftp 
into /home/hrw/devel/build/3541-feed/tmp/deploy/ipk/obexftp_0.10.3-r1_arm.ipk


-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

   Fear leads to anger, anger leads to hate, hate... leads to suffering.
   		-- Yoda

Re: RFC: More granular libraries packaging

[Michael 'Mickey' Lauer]

Am Freitag, den 27.10.2006, 18:01 +0200 schrieb Marcin Juszkiewicz:
> My proposition is - let split each library to separate package. This will 
> enlarge feeds (so ipkg will get hurt more ;( but in some situations can 
> give us smaller rootfs.

+1 from me, however would this be explicit or implicit, i.e. do we need
to opt-in for it to happen (e.g. by inheriting package_libs) or do we
need to opt-out for it _not_ to happen (e.g. by defining
PACKAGE_LIBS_AUTOMATIC = "0").

If we are going to make it opt-in, then for the sake of consistency I'd
favour something along the lines of autotools_stage_all, i.e.

do_package() {
    package_libs_all
}
-- 
Regards,

Michael 'Mickey' Lauer | FreeLancer | http://www.Vanille-Media.de

Re: RFC: More granular libraries packaging

[Øyvind Repvik]

Michael 'Mickey' Lauer wrote:
> Am Freitag, den 27.10.2006, 18:01 +0200 schrieb Marcin Juszkiewicz:
>> My proposition is - let split each library to separate package. This will 
>> enlarge feeds (so ipkg will get hurt more ;( but in some situations can 
>> give us smaller rootfs.
> 
> +1 from me, however would this be explicit or implicit, i.e. do we need
> to opt-in for it to happen (e.g. by inheriting package_libs) or do we
> need to opt-out for it _not_ to happen (e.g. by defining
> PACKAGE_LIBS_AUTOMATIC = "0").

I wouldn't mind it being opt-out, since that makes it somewhat easier 
(imho) to figure out which packages "break" with this change.

Regards,
Øyvind "NAiL" Repvik

Re: RFC: More granular libraries packaging

[Richard Purdie]

On Fri, 2006-10-27 at 18:01 +0200, Marcin Juszkiewicz wrote:
> One of our strong points is granular packaging. We have extra packages for 
> locales, documentation, development stuff etc. But we can improve it a bit 
> more.
> 
> Many packages has multiple libraries in package. Not everytime it is 
> useful - for example libusb had dependency on libstdc++ just because it 
> had libusbpp in same package as libusb.
> 
> My proposition is - let split each library to separate package. This will 
> enlarge feeds (so ipkg will get hurt more ;( but in some situations can 
> give us smaller rootfs.

In some specific cases, splitting packaging per lib makes a lot of
sense. I'd certainly agree in the case of libusb. I'm not sure splitting
all libs is a good idea though as most libs packages are currently
interdependent and there is nothing to be gained by splitting.

I'm therefore thinking of an opt in class/PACKAGEFUNC to handle this
only in the cases we identify as needing it but others seem to have a
different opinion :)

Richard