[oe] The ongoing SRCREV saga

mwester at dls.net mwester at dls.net
Thu Sep 13 01:30:35 UTC 2007


...
> I'm therefore proposing we change bitbake.conf to read:
> 
> SRCREV = "1"
> 
> This puts an end to network access when a SRCREV hasn't been set in
> sane-srcrevs.inc. Anyone wishing to default to svn head in these cases
> can add this to local.conf (or their distro):
> 
> SRCREV = "${AUTOREV}"
> 
> I propose keeping sane-srcrevs.inc for distros to include to have
> meaningful revisions for srcrev based packages.
> 
> If a distro like openmoko wants to make cutting edge development
> possible I suggest creating a .inc file which sets
> 
> SRCREV-pn-whatever = "${AUTOREV}"
> 
> for the packages they want to make floating.
> 
> I firmly believe that floating SRCREVs should be opt in and these
> changes allow that whilst still letting distros or users make use of
> floating versions. I'd also advise openmoko against making SRCREV =
> "${AUTOREV}" the default and to only make the packages they need
> floating but thats not my call to make :).
> 
> Are there any objections to the above? I'll probably commit this fairly
> quickly if the openmoko devs are agreeable.

I firmly vote "YES" on this proposal!

To amplify some of the comments already stated, the principle of "least surprise" suggests strongly that even a very highly-skilled user unfamiliar with OE would expect that any particular OE build environment would remain stable unless the user of that environment explicitly requested otherwise, or unless it is the (preferably formally stated and documented) policy of the specific distro.

This simple change will set the default behavior correctly.  I would further argue that any inconvenience to any particular distro should be minor, as each distro should know exactly what dependencies they have on non-specific SRCREVs, and if they don't, they should want to.  I'll happily fix any issues this might cause for the Unslung and SlugOS distros.    

I look forward to deterministic builds -- luck is for card games, not builds!

Thanks,
Mike (mwester)




More information about the Openembedded-devel mailing list