Discussion: Some type of flag(s) to conditionally build/not build support

[Richard Purdie]

On Tue, 2011-03-22 at 18:25 -0700, Tom Rini wrote:
> Per the last TSC meeting, we agreed that we need to modify OE to have a
> way to get OE to meet both the needs of distributions that maintain a 
> feed (and have end users that create feeds) and users that care much 
> more about initial build time/space than feeds. And it's important that 
> the feed use case people not have to waste time debugging problems 
> introduced by a user that put up a feed and turned off things like 
> someone in the second case would do.
> 
> Mark had some ideas / concerns immediately and it sounded like Richard 
> has had this on the back of his mind for a while.  So, lets start 
> discussing a real solution here.
> 
> I've only got vague ideas at the moment with basically thinking that now 
> that we have a signature generation method, we should utilize that and 
> some form of making the binary packages (ipk, rpm, deb) know about this 
> and depend on this hash.

The various components I suspect we need here are:

a) A mechanism to denote there is a choice of configuration for a recipe
and what the implications of the configuration choice(s) are (i.e.
additional DEPENDS)

b) A mechanism to select those configuration choices. This is policy
configuration so it should be done at the distro level and have the
implications of changing it clearly spelt out for the user.

c) A way to indicate what configuration a given binary package was built
with so compatibility is clear.

We have various developments in progress which help to make certain
things technically possible. Using the basichash signature generator for
example means when someone changes distro configuration, the right
pieces rebuild. We can also inject those hashes into packages in some
way. I'd actually suggest we append them to PR so for example we'd have:

sato-icon-theme-dev_0.4.1-r0-04ace8380c6b0c223bda84bde6e35ffce10b6be9_all.ipk

This way it doesn't change the package feed version decisions but makes
it clear when differences are present?

We also need a way to autoincrement PR values based on the hash.

This leaves a) and b) as the tricky parts. I have some ideas about that
but I'll save those for a follow up email as there are things to think
about here so far...

Cheers,

Richard