Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 2/2] meta: remove redundant _FOR_BUILD variables
Date: Sat, 10 Nov 2012 10:05:05 +0000	[thread overview]
Message-ID: <1352541905.9083.27.camel@ted> (raw)
In-Reply-To: <CAP9ODKpa0gkf5ZQGVemLYRNKVKA4cWbV4v1E_SZwAs9RuMd61A@mail.gmail.com>

On Fri, 2012-11-09 at 21:23 -0200, Otavio Salvador wrote:
> On Fri, Nov 9, 2012 at 8:57 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>         On Fri, 2012-11-09 at 20:32 -0200, Otavio Salvador wrote:
>         > On Fri, Nov 9, 2012 at 8:09 AM, Ross Burton
>         <ross.burton@intel.com>
>         > wrote:
>         >         Signed-off-by: Ross Burton <ross.burton@intel.com>
>         >
>         > Please bump PR. Even it might not change the end result we
>         need to
>         > force a rebuild as we did change the meta-data and we risk
>         having a
>         > subtle bug somewhere.
>
>         This patch set adds a number of exports to autotools.bbclass.
>         In doing
>         so, the sstate checksums will change for pretty much
>         everything and
>         hence pretty much everything will rebuild. Using PR
>         specifically to
>         force a rebuild is therefore unnecessary.
>
> If it rebuilds it might get a different binary package and for
> preserve the upgrade path PR bumps are need, aren't they?

Technically you are correct (I took your comment above to refer to
rebuilding the recipes). Technically we should bump PR for every recipe
using the autotools class.

We don't however bump PR of every recipe every time we change the core
classes and there is plenty of precedent for not doing that.

This is basically why I think the whole "PR bump" thing is flawed and we
should stop doing it in favour of some automated mechanism like PR
service. This is why its high on the 1.4 feature list since I've had
enough of this madness.

I'm not going to ask Ross to spend the hour it would take to manually
bump PR for each recipe using autotools and even that won't account for
PR in other layers.

Cheers,

Richard





  reply	other threads:[~2012-11-10 10:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-09 10:09 [PATCH 0/2] Consolidate _FOR_BUILD variables Ross Burton
2012-11-09 10:09 ` [PATCH 1/2] autotools: set _FOR_BUILD variables here Ross Burton
2012-11-09 10:09 ` [PATCH 2/2] meta: remove redundant _FOR_BUILD variables Ross Burton
2012-11-09 22:32   ` Otavio Salvador
2012-11-09 22:57     ` Richard Purdie
2012-11-09 23:23       ` Otavio Salvador
2012-11-10 10:05         ` Richard Purdie [this message]
2012-11-10 11:11         ` Phil Blundell
2012-11-10 11:20           ` Tomas Frydrych

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1352541905.9083.27.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio@ossystems.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox