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

[Koen Kooi]

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?

regards,

Koen