[oe] [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.

[Chris Larson]

On Thu, May 14, 2009 at 8:56 PM, Mike Westerhof (mwester)
<mwester at dls.net> wrote:
> Chris Larson wrote:
>> For each recipe which completes a task successfully, this emits the current
>> version into ${TMPDIR}/versions.conf as a PREFERRED_VERSION line.
>> ${TMPDIR}/versions.conf and conf/versions.conf are automatically included,
>> in that order, in subsequent builds, to provide more deterinistic builds by
>> default, and to let the user make the lockdown persist via a simple cp
>> command...
>
> Excellent! This is much needed as a feature.  The usage model seems to
> be a very reasonable one, and would tend to be consistent with what
> users sort of expect for a workflow.
>
> I say "sort of expect" because I think they would rather see the
> management of the versions.conf file be done by bitbake.  For example,
> the "bitbake crystallize" command (to choose a name) might do no build
> at all, but just generate, or re-generate, the versions.conf file.  But
> that's a trivial point; they'll have to remember to cp or rm
> versions.conf as necessary themselves.

Aye, Phil Blundell and I were discussing this on IRC yesterday.  This
is mostly a hack around the fact that bitbake should never have
defaulted to the latest version of a package to begin with.  But in
order to fix that, we'd need a new/better mechanism for the user to
express what they want in a build.

> The only big concern that I have is that this is really quite a drastic
> change in behavior for the "cookbook-type" OE user community out there
> (the folks who have memorized a set of procedures to build their distro
> images without any real understanding of how it works).  How do we
> propose to roll out this change?

It does change behavior, but only within the context of a single tmp
directory existance.  I doubt anyone in particular relies on their
build suddenly switching to a newer version of something when the
newer version shows up in the repository, but perhaps they do.  I
expect the biggest change is that doing "bitbake foo-1.0" rather than
the default of foo 1.2 would result in it continuing to build foo 1.0
going forward, rather than that being a temporary change.

Honestly, I'm not sure how best to smoothly roll something like this
out.  I don't think you can make it any less intrusive for a default
behavior without modifying bitbake.  Obviously, we could make it not
be default, but I don't know how I feel about that, either.  I guess
thatd be best, to avoid breaking people's scripts, but I still quite
dislike the current bitbake version behavior, personally.

Anyone have any ideas on this?
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.