Re: [PULL]Fix adding GDBM_File module for perl

[Richard Purdie <rpurdie@linux.intel.com>]

On Mon, 2010-11-01 at 14:32 -0500, Mark Hatle wrote:
> I've been doing some thinking about how various perl and related components 
> should be implemented if they do potentially optional things.
> 
> My concern is that by adding gdbm to the build, that other components will 
> change and potentially require more disk space.  We really need a way to 
> optionally use gdbm, if available in these configurations.  I'm really not sure 
> if there is currently a way to tell bitbake:
> 
> I really want gdbm, but if nothing else wants it.. I don't want it.  Then for 
> LSB specific builds, we manually require gdbm as an LSB requirement (due to the 
> gdbm perl module requirements.)
> 
> Richard, any suggestions on how to work with this?

The trouble is the configuration is entirely deterministic by design. At
this point people start talking about Gentoo USE flags and how we should
add them and how wonderful the world would be.

To talk through the use case, I run "bitbake poky-image-sato" which lets
say doesn't need gdbm so perl is built without gdbm.

I then "bitbake poky-image-sdk" which does include it. Does perl get
rebuilt?

Another issue is the perl packages themselves. These can differ
depending on whether gdbm was included or not. If I hand you two perl
package rpms, how do you tell the difference?

Obviously you can mark them somehow or embed data into them but there is
no mechanism for this in some packaging systems. It makes maintenance of
feeds very hard as the build order can drastically change the contents
of the feeds.

One "middle ground" solution I've considered is extended use of the
DISTRO_FEATURES variable. By default this would be a pretty inclusive
list of things like "gdbm". The perl recipe would only include gdbm if
it was included in the list. The user can then customise the
DISTRO_FEATURES list and remove things they don't care about. Presumably
under this scenario, gdbm itself could exit with an error if someone
tried to build it and it wasn't listed.

Checksums will allow us to handle dynamically rebuilding anything that
changes when you edit that variable.

Does that give us a solution that would work for you?

Cheers,

Richard