The ongoing SRCREV saga

The ongoing SRCREV saga

[Richard Purdie]

[This was meant for the OE list and autocomplete didn't quite do what
I'd intended with the recipients originally, sorry :/]

There is a certain amount of friction in the community regarding the
recent SRCREV additions of which I've received my share.

The concerns are really about how we're using SRCREV in OE rather than
about the bitbake implementation itself which is an important
distinction.

The basic problem is that people view the change as making parsing
dependent on network access which was never the intent. If people added
a revision to sane-srcrevs.inc every time they added a SRCREV based .bb
file we wouldn't have a problem and parsing never would depend on
network access. I'm living on another planet if I expect that to happen
in reality though so this approach simply isn't going to work though.

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.

Cheers

Richard

Re: The ongoing SRCREV saga

[Michael 'Mickey' Lauer]

Hi Richard,

thanks for your proposal. I fully agree with all of your points. I
really like the SRCREV feature, but at the same time I can see how it
can impose problems for a lot of people. I think making it opt-in
rather than opt-out is the right thing to do -- please go ahead!

Thanks again,

Mickey.

-- 
- Michael Lauer <mickey@openmoko.org>                   http://openmoko.org/
============================================================================
Software for the worlds' first truly open Free Software mobile phone

Re: The ongoing SRCREV saga

[mwester]

...
> 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)

Re: The ongoing SRCREV saga

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
> [This was meant for the OE list and autocomplete didn't quite do what
> I'd intended with the recipients originally, sorry :/]
> 
> There is a certain amount of friction in the community regarding the
> recent SRCREV additions of which I've received my share.
> 
> The concerns are really about how we're using SRCREV in OE rather than
> about the bitbake implementation itself which is an important
> distinction.
> 
> The basic problem is that people view the change as making parsing
> dependent on network access which was never the intent. If people added
> a revision to sane-srcrevs.inc every time they added a SRCREV based .bb
> file we wouldn't have a problem and parsing never would depend on
> network access. I'm living on another planet if I expect that to happen
> in reality though so this approach simply isn't going to work though.
> 
> 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}"

or 'require conf/distro/insane-srcrevs.inc'

> I propose keeping sane-srcrevs.inc for distros to include to have
> meaningful revisions for srcrev based packages.

Angstrom includes it now by default.

> If a distro like openmoko wants to make cutting edge development
> possible I suggest creating a .inc file which sets
> 
> SRCREV-pn-whatever = "${AUTOREV}"

'require conf/distro/include/moko-autorev.inc'

> 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.

Mickey OK'ed it on another list, so I added sane-srcrevs.inc to angstrom. (in)sane-srcrevs
and moko-autorev needs some tweaking, but 90% is there.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFG6O0PMkyGM64RGpERAuaOAKCnIGW1yzZu0yh+Qd8vzvDP3LUhWwCdE48L
wR/Y3/kaYE9SPiuKNz0aqas=
=oeJo
-----END PGP SIGNATURE-----

Re: The ongoing SRCREV saga

[Richard Purdie]

On Thu, 2007-09-13 at 09:55 +0200, Koen Kooi wrote:
> Richard Purdie schreef:
> > Are there any objections to the above? I'll probably commit this fairly
> > quickly if the openmoko devs are agreeable.
> 
> Mickey OK'ed it on another list, so I added sane-srcrevs.inc to angstrom. (in)sane-srcrevs
> and moko-autorev needs some tweaking, but 90% is there.

Thanks for that, I've completed the change tweaking these files a little
and changing the default SRCREV definition as discussed.

Cheers,

Richard