All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>,
	<bitbake-devel@lists.openembedded.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [RFC bitbake][RFC PATCH 1/1] cooker: rework LAYERDEPENDS versioning so that it is actually useful
Date: Thu, 29 Jan 2015 11:25:52 -0600	[thread overview]
Message-ID: <54CA6D20.4010604@windriver.com> (raw)
In-Reply-To: <e1f6bd9ed8e0a1b89277af10e0d9af17ec8efd86.1422539142.git.paul.eggleton@linux.intel.com>

On 1/29/15 7:49 AM, Paul Eggleton wrote:
> We've had versioned dependency support in LAYERDEPENDS for quite a long
> time, but I can say with pretty good certainty that almost nobody has
> used it because it was too strict - the specified version had to exactly
> match the version in your configuration or you would get an error; there
> was no "greater than or equal" option, which is usually what you will
> want given that LAYERVERSION does get bumped.
> 
> However, users mismatching layer branches and then having their builds
> fail later on with some incomprehensible error is still a pretty common
> problem. To address this, I have reworked LAYERDEPENDS version
> specifications to use the more familiar "dependency (>= version)" syntax
> as used with package dependencies, support non-integer versions, and
> clarified the error message a little. If we then take care to bump the
> version on every breaking change, it is at least possible to have layers
> depend on these changes when they update to match; we can now even
> support a major.minor scheme to allow retrospectively adding a version
> limiter to old branches when a new branch is created and yet still allow
> the old branch minor version to be bumped if needed.
> 
> Fixes [YOCTO #5991].
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

I've run into this exact support situation as well.  I think we need to do
something like this >, =, <, etc.. so that we can add the necessary keys to
layers to more clearly indicate what is and isn't supported (combination wise.)

I'm all for this!

--Mark


WARNING: multiple messages have this Message-ID (diff)
From: Mark Hatle <mark.hatle@windriver.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>,
	<bitbake-devel@lists.openembedded.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [bitbake-devel] [RFC bitbake][RFC PATCH 1/1] cooker: rework LAYERDEPENDS versioning so that it is actually useful
Date: Thu, 29 Jan 2015 11:25:52 -0600	[thread overview]
Message-ID: <54CA6D20.4010604@windriver.com> (raw)
In-Reply-To: <e1f6bd9ed8e0a1b89277af10e0d9af17ec8efd86.1422539142.git.paul.eggleton@linux.intel.com>

On 1/29/15 7:49 AM, Paul Eggleton wrote:
> We've had versioned dependency support in LAYERDEPENDS for quite a long
> time, but I can say with pretty good certainty that almost nobody has
> used it because it was too strict - the specified version had to exactly
> match the version in your configuration or you would get an error; there
> was no "greater than or equal" option, which is usually what you will
> want given that LAYERVERSION does get bumped.
> 
> However, users mismatching layer branches and then having their builds
> fail later on with some incomprehensible error is still a pretty common
> problem. To address this, I have reworked LAYERDEPENDS version
> specifications to use the more familiar "dependency (>= version)" syntax
> as used with package dependencies, support non-integer versions, and
> clarified the error message a little. If we then take care to bump the
> version on every breaking change, it is at least possible to have layers
> depend on these changes when they update to match; we can now even
> support a major.minor scheme to allow retrospectively adding a version
> limiter to old branches when a new branch is created and yet still allow
> the old branch minor version to be bumped if needed.
> 
> Fixes [YOCTO #5991].
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

I've run into this exact support situation as well.  I think we need to do
something like this >, =, <, etc.. so that we can add the necessary keys to
layers to more clearly indicate what is and isn't supported (combination wise.)

I'm all for this!

--Mark


  reply	other threads:[~2015-01-29 17:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29 13:49 [bitbake][RFC PATCH 0/1] Proposed fix for layer branch mismatch issue Paul Eggleton
2015-01-29 13:49 ` [RFC bitbake][RFC PATCH 1/1] cooker: rework LAYERDEPENDS versioning so that it is actually useful Paul Eggleton
2015-01-29 17:25   ` Mark Hatle [this message]
2015-01-29 17:25     ` [bitbake-devel] " Mark Hatle

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=54CA6D20.4010604@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /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 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.