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

[Richard Purdie]

On Thu, 2011-03-31 at 22:09 +0200, Koen Kooi wrote:
> Op 31 mrt 2011, om 22:04 heeft Richard Purdie het volgende geschreven:
> 
> > 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...
> 
> I think a nice intermediate step is to use the config hash in e.g.
> DEPLOYDIR so you get a seperate output dir after each change. Can we
> shorten the hash a bit, e.g. 8 chars?

The hash that I was thinking of is the one for the ipk write package
task itself so it encapsulates all the configuration information that
went into that package and would match the sstate version. That hash is
of course per package so not suited to DEPLOYDIR use. The advantage is
if you have the corresponding siginfo files around, you can get an awful
lot of information about the configuration associated with the package.

We could have a hash which represented some specific data and was
injected into a PATH though, that is equally possible.

Cheers,

Richard