All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
@ 2009-05-13 20:53 Chris Larson
  2009-05-13 21:25 ` Denys Dmytriyenko
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Chris Larson @ 2009-05-13 20:53 UTC (permalink / raw)
  To: openembedded-devel

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.

Assuming that the latest ncurses in the recipes is 5.7, and that 5.7 is
preferred over 5.3 by default given any distro version preferences, if they
exist, the following are examples of its behavior:

$ rm -rf tmp
$ bitbake ncurses-5.3
$ bitbake -c clean ncurses
$ bitbake ncurses # builds ncurses 5.3

$ cp tmp/versions.conf conf/
$ rm -rf tmp
$ bitbake ncurses # builds ncurses 5.3

Signed-off-by: Chris Larson <clarson@mvista.com>
---
 conf/bitbake.conf |    1 +
 conf/freeze.inc   |   71 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 72 insertions(+), 0 deletions(-)
 create mode 100644 conf/freeze.inc

diff --git a/conf/bitbake.conf b/conf/bitbake.conf
index f7df60c..9b6ffcc 100644
--- a/conf/bitbake.conf
+++ b/conf/bitbake.conf
@@ -618,6 +618,7 @@ OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUIL
 ##################################################################
 
 require conf/collections.inc
+require conf/freeze.inc
 include conf/site.conf
 include conf/auto.conf
 include conf/local.conf
diff --git a/conf/freeze.inc b/conf/freeze.inc
new file mode 100644
index 0000000..82acebf
--- /dev/null
+++ b/conf/freeze.inc
@@ -0,0 +1,71 @@
+# Recipe version "freeze" aka lockdown implementation.
+#
+# 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.
+#
+# Assuming that the latest ncurses in the recipes is 5.7, and that 5.7 is
+# preferred over 5.3 by default given any distro version preferences, if they
+# exist, the following are examples of its behavior:
+#
+# $ rm -rf tmp
+# $ bitbake ncurses-5.3
+# $ bitbake -c clean ncurses
+# $ bitbake ncurses # builds ncurses 5.3
+#
+# $ cp tmp/versions.conf conf/
+# $ rm -rf tmp
+# $ bitbake ncurses # builds ncurses 5.3
+
+__FREEZEFN ?= "versions.conf"
+__FREEZEFILE = "${TMPDIR}/${__FREEZEFN}"
+__FREEZELINE = 'PREFERRED_VERSION_%s = "%s"'
+__FREEZELINERE = '^PREFERRED_VERSION_(.*) = "(.*)"$'
+
+include ${__FREEZEFILE}
+include conf/${__FREEZEFN}
+
+def freeze_add(d):
+    fn = d.getVar("__FREEZEFILE", 1)
+    f = open(fn, "a")
+    f.write("%s\n" % (d.getVar("__FREEZELINE", 1) % (d.getVar("PN", 1), d.getVar("PV", 1))))
+    f.close()
+
+def freeze_finish(d):
+    import re
+
+    # Cleaning up the freezefile
+    freezefile = d.getVar("__FREEZEFILE", 1)
+    verdata = {}
+
+    try:
+        f = open(freezefile, "r")
+    except (OSError, IOError):
+        pass
+
+    regexp = re.compile(d.getVar("__FREEZELINERE", 1))
+    for line in f:
+        m = regexp.match(line)
+        verdata[m.group(1)] = m.group(2)
+    f.close()
+
+    fl = d.getVar("__FREEZELINE", 1)
+    f = open(freezefile, "w")
+    f.writelines([("%s\n" % (fl % (pn, pv))) for (pn, pv) in verdata.items()])
+    f.close()
+
+addhandler freeze_eventhandler
+python freeze_eventhandler () {
+    from bb.event import BuildCompleted
+    from bb.build import TaskSucceeded
+
+    if isinstance(e, TaskSucceeded):
+        freeze_add(e.data)
+    elif isinstance(e, BuildCompleted):
+        freeze_finish(e.data)
+}
+
+# vim: set ft=bitbake fenc=utf-8 sts=4 sw=4 et :
-- 
1.6.2




^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-13 20:53 [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default Chris Larson
@ 2009-05-13 21:25 ` Denys Dmytriyenko
  2009-05-18 15:48   ` Denys Dmytriyenko
  2009-05-15  3:56 ` Mike Westerhof (mwester)
  2009-05-15 15:55 ` Michael Smith
  2 siblings, 1 reply; 14+ messages in thread
From: Denys Dmytriyenko @ 2009-05-13 21:25 UTC (permalink / raw)
  To: openembedded-devel

On Wed, May 13, 2009 at 01:53:18PM -0700, 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.
> 
> Assuming that the latest ncurses in the recipes is 5.7, and that 5.7 is
> preferred over 5.3 by default given any distro version preferences, if they
> exist, the following are examples of its behavior:
> 
> $ rm -rf tmp
> $ bitbake ncurses-5.3
> $ bitbake -c clean ncurses
> $ bitbake ncurses # builds ncurses 5.3
> 
> $ cp tmp/versions.conf conf/
> $ rm -rf tmp
> $ bitbake ncurses # builds ncurses 5.3

Very nice! Let me try it here...

> Signed-off-by: Chris Larson <clarson@mvista.com>
> ---
>  conf/bitbake.conf |    1 +
>  conf/freeze.inc   |   71 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 72 insertions(+), 0 deletions(-)
>  create mode 100644 conf/freeze.inc
> 
> diff --git a/conf/bitbake.conf b/conf/bitbake.conf
> index f7df60c..9b6ffcc 100644
> --- a/conf/bitbake.conf
> +++ b/conf/bitbake.conf
> @@ -618,6 +618,7 @@ OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUIL
>  ##################################################################
>  
>  require conf/collections.inc
> +require conf/freeze.inc
>  include conf/site.conf
>  include conf/auto.conf
>  include conf/local.conf
> diff --git a/conf/freeze.inc b/conf/freeze.inc
> new file mode 100644
> index 0000000..82acebf
> --- /dev/null
> +++ b/conf/freeze.inc
> @@ -0,0 +1,71 @@
> +# Recipe version "freeze" aka lockdown implementation.
> +#
> +# 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.
> +#
> +# Assuming that the latest ncurses in the recipes is 5.7, and that 5.7 is
> +# preferred over 5.3 by default given any distro version preferences, if they
> +# exist, the following are examples of its behavior:
> +#
> +# $ rm -rf tmp
> +# $ bitbake ncurses-5.3
> +# $ bitbake -c clean ncurses
> +# $ bitbake ncurses # builds ncurses 5.3
> +#
> +# $ cp tmp/versions.conf conf/
> +# $ rm -rf tmp
> +# $ bitbake ncurses # builds ncurses 5.3
> +
> +__FREEZEFN ?= "versions.conf"
> +__FREEZEFILE = "${TMPDIR}/${__FREEZEFN}"
> +__FREEZELINE = 'PREFERRED_VERSION_%s = "%s"'
> +__FREEZELINERE = '^PREFERRED_VERSION_(.*) = "(.*)"$'
> +
> +include ${__FREEZEFILE}
> +include conf/${__FREEZEFN}
> +
> +def freeze_add(d):
> +    fn = d.getVar("__FREEZEFILE", 1)
> +    f = open(fn, "a")
> +    f.write("%s\n" % (d.getVar("__FREEZELINE", 1) % (d.getVar("PN", 1), d.getVar("PV", 1))))
> +    f.close()
> +
> +def freeze_finish(d):
> +    import re
> +
> +    # Cleaning up the freezefile
> +    freezefile = d.getVar("__FREEZEFILE", 1)
> +    verdata = {}
> +
> +    try:
> +        f = open(freezefile, "r")
> +    except (OSError, IOError):
> +        pass
> +
> +    regexp = re.compile(d.getVar("__FREEZELINERE", 1))
> +    for line in f:
> +        m = regexp.match(line)
> +        verdata[m.group(1)] = m.group(2)
> +    f.close()
> +
> +    fl = d.getVar("__FREEZELINE", 1)
> +    f = open(freezefile, "w")
> +    f.writelines([("%s\n" % (fl % (pn, pv))) for (pn, pv) in verdata.items()])
> +    f.close()
> +
> +addhandler freeze_eventhandler
> +python freeze_eventhandler () {
> +    from bb.event import BuildCompleted
> +    from bb.build import TaskSucceeded
> +
> +    if isinstance(e, TaskSucceeded):
> +        freeze_add(e.data)
> +    elif isinstance(e, BuildCompleted):
> +        freeze_finish(e.data)
> +}
> +
> +# vim: set ft=bitbake fenc=utf-8 sts=4 sw=4 et :
> -- 
> 1.6.2
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-13 20:53 [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default Chris Larson
  2009-05-13 21:25 ` Denys Dmytriyenko
@ 2009-05-15  3:56 ` Mike Westerhof (mwester)
  2009-05-15  7:33   ` Andrea Adami
                     ` (2 more replies)
  2009-05-15 15:55 ` Michael Smith
  2 siblings, 3 replies; 14+ messages in thread
From: Mike Westerhof (mwester) @ 2009-05-15  3:56 UTC (permalink / raw)
  To: openembedded-devel

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.

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?

-Mike (mwester)



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-15  3:56 ` Mike Westerhof (mwester)
@ 2009-05-15  7:33   ` Andrea Adami
  2009-05-15 15:09     ` Chris Larson
  2009-05-15  8:24   ` Graeme Gregory
  2009-05-15 15:08   ` Chris Larson
  2 siblings, 1 reply; 14+ messages in thread
From: Andrea Adami @ 2009-05-15  7:33 UTC (permalink / raw)
  To: openembedded-devel

>How do we
>propose to roll out this change?

What about adding a -u (update) option? This would just give old behaviour.

My 2 (euro)cents

Andrea



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-15  3:56 ` Mike Westerhof (mwester)
  2009-05-15  7:33   ` Andrea Adami
@ 2009-05-15  8:24   ` Graeme Gregory
  2009-05-15 15:08   ` Chris Larson
  2 siblings, 0 replies; 14+ messages in thread
From: Graeme Gregory @ 2009-05-15  8:24 UTC (permalink / raw)
  To: openembedded-devel

On 05/15/2009 04:56 AM, Mike Westerhof (mwester) wrote:
>
> 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.
>
>    
Holger (zecke) wrote exactly this task for openmoko, it is most likely 
still in the openmoko git tree.

Graeme




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-15  3:56 ` Mike Westerhof (mwester)
  2009-05-15  7:33   ` Andrea Adami
  2009-05-15  8:24   ` Graeme Gregory
@ 2009-05-15 15:08   ` Chris Larson
  2009-05-15 16:02     ` Tom Rini
  2 siblings, 1 reply; 14+ messages in thread
From: Chris Larson @ 2009-05-15 15:08 UTC (permalink / raw)
  To: openembedded-devel; +Cc: openembedded-devel

On Thu, May 14, 2009 at 8:56 PM, Mike Westerhof (mwester)
<mwester@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.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-15  7:33   ` Andrea Adami
@ 2009-05-15 15:09     ` Chris Larson
  2009-05-15 21:07       ` Andrea Adami
  0 siblings, 1 reply; 14+ messages in thread
From: Chris Larson @ 2009-05-15 15:09 UTC (permalink / raw)
  To: openembedded-devel

On Fri, May 15, 2009 at 12:33 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
>>How do we
>>propose to roll out this change?
>
> What about adding a -u (update) option? This would just give old behaviour.

I don't understand what you'd want -u to do?  This patch doesn't
modify bitbake, so it doesn't mess with commandline arguments at all.
Are you arguing for a variable which could be set to disable this
functionality?  That would seem like a reasonable thing to do, though
I doubt anyone would actually want to disable it, once they get used
to it.
-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-13 20:53 [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default Chris Larson
  2009-05-13 21:25 ` Denys Dmytriyenko
  2009-05-15  3:56 ` Mike Westerhof (mwester)
@ 2009-05-15 15:55 ` Michael Smith
  2 siblings, 0 replies; 14+ messages in thread
From: Michael Smith @ 2009-05-15 15:55 UTC (permalink / raw)
  To: openembedded-devel

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.

Hi Chris,

If a distro doesn't lock down a particular version of a package, I 
figure after a "git pull" I'll be building the latest version of 
everything. At least, if I do a "bitbake -c clean somepkg" followed by a 
"bitbake somepkg", I'll get the latest version of somepkg.

If I understand the patch correctly, that won't happen anymore unless I 
remember to remove tmp/versions.conf. It adds an extra step to the 
process when one developer is using another's package.

I can see it leading to confusion between developers. Any time there's a 
multi-step process, humans will find a way to forget a step. :)

What's the problem the versions.conf is meant to solve? I would think if 
I'm doing a git pull and then rebuilding a package, it's because I want 
to get the latest version, but I think I'm missing something here.

Mike



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-15 15:08   ` Chris Larson
@ 2009-05-15 16:02     ` Tom Rini
  0 siblings, 0 replies; 14+ messages in thread
From: Tom Rini @ 2009-05-15 16:02 UTC (permalink / raw)
  To: openembedded-devel

On Fri, May 15, 2009 at 08:08:29AM -0700, Chris Larson wrote:
[snip]
> 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

People with buildbots (hrw, myself, I'm sure others) do, for our
incremental builds.  But of course, the reason for incremental builds is
the behavior that this would change.

-- 
Tom Rini



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-15 15:09     ` Chris Larson
@ 2009-05-15 21:07       ` Andrea Adami
  2009-05-18 15:44         ` Denys Dmytriyenko
  0 siblings, 1 reply; 14+ messages in thread
From: Andrea Adami @ 2009-05-15 21:07 UTC (permalink / raw)
  To: openembedded-devel

>> What about adding a -u (update) option? This would just give old behaviour.
>
> I don't understand what you'd want -u to do?  This patch doesn't
> modify bitbake,

Why? Taboo?
Adding the 'update' option to bitbake would be logic at this point.
Buildscripts would just have to change to 'bitbake -u'.

(see Gentoo's emerge)

Regards

Andrea



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-15 21:07       ` Andrea Adami
@ 2009-05-18 15:44         ` Denys Dmytriyenko
  0 siblings, 0 replies; 14+ messages in thread
From: Denys Dmytriyenko @ 2009-05-18 15:44 UTC (permalink / raw)
  To: openembedded-devel

On Fri, May 15, 2009 at 11:07:33PM +0200, Andrea Adami wrote:
> >> What about adding a -u (update) option? This would just give old behaviour.
> >
> > I don't understand what you'd want -u to do?  This patch doesn't
> > modify bitbake,
> 
> Why? Taboo?
> Adding the 'update' option to bitbake would be logic at this point.
> Buildscripts would just have to change to 'bitbake -u'.
> 
> (see Gentoo's emerge)

I guess since bitbake is not part of OE (unlike Gentoo's emerge/portage), it 
is less transparent for introducing new features like this one...

-- 
Denys




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-13 21:25 ` Denys Dmytriyenko
@ 2009-05-18 15:48   ` Denys Dmytriyenko
  2009-05-18 18:00     ` Christopher Larson
  0 siblings, 1 reply; 14+ messages in thread
From: Denys Dmytriyenko @ 2009-05-18 15:48 UTC (permalink / raw)
  To: openembedded-devel

On Wed, May 13, 2009 at 05:25:46PM -0400, Denys Dmytriyenko wrote:
> On Wed, May 13, 2009 at 01:53:18PM -0700, 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.
> > 
> > Assuming that the latest ncurses in the recipes is 5.7, and that 5.7 is
> > preferred over 5.3 by default given any distro version preferences, if they
> > exist, the following are examples of its behavior:
> > 
> > $ rm -rf tmp
> > $ bitbake ncurses-5.3
> > $ bitbake -c clean ncurses
> > $ bitbake ncurses # builds ncurses 5.3
> > 
> > $ cp tmp/versions.conf conf/
> > $ rm -rf tmp
> > $ bitbake ncurses # builds ncurses 5.3
> 
> Very nice! Let me try it here...
> 
> > Signed-off-by: Chris Larson <clarson@mvista.com>

Chris,

Will you be sending an updated version of the patch, which handles TMPDIR 
overwritten in local.conf, as we discussed last week? Thanks.

-- 
Denys



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-18 15:48   ` Denys Dmytriyenko
@ 2009-05-18 18:00     ` Christopher Larson
  2009-05-18 18:58       ` Denys Dmytriyenko
  0 siblings, 1 reply; 14+ messages in thread
From: Christopher Larson @ 2009-05-18 18:00 UTC (permalink / raw)
  To: openembedded-devel

Denys Dmytriyenko wrote:
> On Wed, May 13, 2009 at 05:25:46PM -0400, Denys Dmytriyenko wrote:
>   
>> On Wed, May 13, 2009 at 01:53:18PM -0700, 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.
>>>
>>> Assuming that the latest ncurses in the recipes is 5.7, and that 5.7 is
>>> preferred over 5.3 by default given any distro version preferences, if they
>>> exist, the following are examples of its behavior:
>>>
>>> $ rm -rf tmp
>>> $ bitbake ncurses-5.3
>>> $ bitbake -c clean ncurses
>>> $ bitbake ncurses # builds ncurses 5.3
>>>
>>> $ cp tmp/versions.conf conf/
>>> $ rm -rf tmp
>>> $ bitbake ncurses # builds ncurses 5.3
>>>       
>> Very nice! Let me try it here...
>>
>>     
>>> Signed-off-by: Chris Larson <clarson@mvista.com>
>>>       
>
> Chris,
>
> Will you be sending an updated version of the patch, which handles TMPDIR 
> overwritten in local.conf, as we discussed last week? Thanks.
Yep, I'm going to make the thing opt-in rather than default, since 
apparently not everyone wants it as default behavior, and change it to 
use ?= assignments, and leave it at that.

-Chris



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default.
  2009-05-18 18:00     ` Christopher Larson
@ 2009-05-18 18:58       ` Denys Dmytriyenko
  0 siblings, 0 replies; 14+ messages in thread
From: Denys Dmytriyenko @ 2009-05-18 18:58 UTC (permalink / raw)
  To: openembedded-devel

On Mon, May 18, 2009 at 11:00:11AM -0700, Christopher Larson wrote:
> Denys Dmytriyenko wrote:
>> On Wed, May 13, 2009 at 05:25:46PM -0400, Denys Dmytriyenko wrote:
>>   
>>> On Wed, May 13, 2009 at 01:53:18PM -0700, 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.
>>>>
>>>> Assuming that the latest ncurses in the recipes is 5.7, and that 5.7 is
>>>> preferred over 5.3 by default given any distro version preferences, if 
>>>> they
>>>> exist, the following are examples of its behavior:
>>>>
>>>> $ rm -rf tmp
>>>> $ bitbake ncurses-5.3
>>>> $ bitbake -c clean ncurses
>>>> $ bitbake ncurses # builds ncurses 5.3
>>>>
>>>> $ cp tmp/versions.conf conf/
>>>> $ rm -rf tmp
>>>> $ bitbake ncurses # builds ncurses 5.3
>>>>       
>>> Very nice! Let me try it here...
>>>
>>>     
>>>> Signed-off-by: Chris Larson <clarson@mvista.com>
>>>>       
>>
>> Chris,
>>
>> Will you be sending an updated version of the patch, which handles TMPDIR 
>> overwritten in local.conf, as we discussed last week? Thanks.
> Yep, I'm going to make the thing opt-in rather than default, since 
> apparently not everyone wants it as default behavior, and change it to use 
> ?= assignments, and leave it at that.

Hmm, I'm using the updated version of freeze.inc with weak assignments and 
there seems to be an issue with picking the correct version. Or maybe I'm 
doing something wrong...

I have a customized u-boot recipe, based on 1.3.4, which sets PV as "1.3.4" 
and PR as "myX.Y.Z". Having 2 revisions of the above recipe with X.Y.Z = 
"2.0.0" and "2.1.0", by default BitBake picks the correct one with higher PR - 
i.e. "1.3.4-my2.1.0". Then when freeze.inc sets PREFERRED_VERSION to "1.3.4", 
it starts picking the lowest version, i.e. "1.3.4-my2.0.0". What gives? Any 
ideas?

-- 
Denys



^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2009-05-18 19:06 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-13 20:53 [PATCH] bitbake.conf, freeze.inc: Add version lockdown implementation and use it by default Chris Larson
2009-05-13 21:25 ` Denys Dmytriyenko
2009-05-18 15:48   ` Denys Dmytriyenko
2009-05-18 18:00     ` Christopher Larson
2009-05-18 18:58       ` Denys Dmytriyenko
2009-05-15  3:56 ` Mike Westerhof (mwester)
2009-05-15  7:33   ` Andrea Adami
2009-05-15 15:09     ` Chris Larson
2009-05-15 21:07       ` Andrea Adami
2009-05-18 15:44         ` Denys Dmytriyenko
2009-05-15  8:24   ` Graeme Gregory
2009-05-15 15:08   ` Chris Larson
2009-05-15 16:02     ` Tom Rini
2009-05-15 15:55 ` Michael Smith

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.