[oe] no-distro goal and SRCREV=1 in bitbake.conf

Richard Purdie rpurdie at rpsys.net
Tue Oct 16 21:38:11 UTC 2007


On Tue, 2007-10-16 at 17:19 +0100, Graeme Gregory wrote:
> On Tue, 16 Oct 2007 15:56:37 +0200
> Koen Kooi <k.kooi at student.utwente.nl> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hi,
> > 
> > SRCREV=1 in bitbake.conf forces people to use a distro, which is
> > bad(TM) according to the OEDEM minutes.
> > 
> > My short term solution:
> > 
> > * SRCREV = "${@bb.fetch.get_srcrev(d)}" in bitbake.conf
> > * SRCREV ?= <foo> in recipes
> > * SRCREV_pn-baz ?= <bar> in distro includes or local.conf
> > 
> > For the medium and long term we should consider adding snapshot
> > recipes for 'proven' revisions next to the 'floating' ones, even if
> > Richard thinks it's a waste of space. Having a host of 'unbreak me'
> > includes is also against our 'sane defaults' goal we decided on at
> > OEDEM.
> > 
> > Comments/ideas/flames?
> > 
> 
> My opinion is with the goal to build with no DISTRO= set then no
> software should be build with floating SVN versions by default.
> 
> So I would opt for the "snapshot" releases style that we have been doing
> for a long time now anyway. For stuff that is needed for basic images
> but has never had a working release.

To put my comment into context, I regard recipes that do SRCREV = "123"
as a waste of space as we may as well just use the svn version for that
with a value for SRCREV set. All the extra recipe does is increase
parsing time by adding files.

If a tarball is created and used for a given recipe that is a bit
different. Is that any different to using the svn recipe with a locked
down SRCREV and a decent tarball mirror source though?

In general the people who want floating recipes know exactly who they
are and what they want. The openmoko people want a certain set of
packages floating and thats fine and definable. They wouldn't want
something like glibc floating for example. I don't think anyone wants
floating everything. This suggests floating recipes should be opt-in.

I'd therefore propose SRCREV="1" stays and sane-srcrevs is included as
standard, containing ?= (it already does) so users/distros/whatever can
override as they see fit.

If we want to change that policy to SRCREV ?= <foo> in recipes, I'm ok
with that and perhaps it would be more obvious, I don't know...

Yes, there are also some issues to do with educating people about minrev
and maxrev but I'm sure with time that can be sorted out and it is
mainly an education issue.

Cheers,

Richard






More information about the Openembedded-devel mailing list