archive mirror
 help / color / mirror / Atom feed
From: Richard Purdie <>
To: Peter Kjellerstedt <>,
	Steve Sakoman <>
Cc: Frederic Martinsons <>,
Subject: Re: [bitbake-devel][PATCH v2 3/3] authorize crate url with parameters
Date: Thu, 06 Apr 2023 12:12:49 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, 2023-04-06 at 10:56 +0000, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From: Richard Purdie <>
> > Sent: den 6 april 2023 10:43
> > To: Peter Kjellerstedt <>; Steve Sakoman
> > <>
> > Cc: Frederic Martinsons <>; bitbake-
> >
> > Subject: Re: [bitbake-devel][PATCH v2 3/3] authorize crate url
> > with parameters
> > 
> > On Thu, 2023-04-06 at 03:40 +0000, Peter Kjellerstedt wrote:
> > > Please cherry-pick this to Kirkstone and Langdale so that they can read
> > > updated recipes that use crate:// URIs with parameters.
> > > 
> > > I assume it should be ok to cherry-pick part one of this series too, as
> > > long as you do not cherry-pick part two, as it would be a breaking
> > change.
> > 
> > If we do this does this mean we're committing to forwards compatibility? 
> > I'm not sure I like that precedent...
> While not a requirement, I sure hope we can strive for forward compatibility 
> where it does not impact the older branches negatively. At least in cases 
> where it affects parsability or involves parts that are hard to override 
> in a higher layer.

The trouble is I take this patch, then next time something breaks you
tell me "in the past such changes were only made so that this didn't
break things" and quote it as precedent.

I worry a lot about people relying upon us doing this as it isn't a
guarantee we've ever made.

> The problem for me in this case is that Mickledore now requires that all 
> URIs have a checksum, which basically requires that parameters are used 
> for the crate:// URIs since it is quite common that recipes depend on
> multiple versions of the same crate and thus requires the name= parameter. 
> At the same time the crate fetcher in Kirkstone and Langdale will fail 
> if any parameters are specified for the URIs. This means it is not possible 
> to use the same version of the generated files, which causes 
> a lot of maintenance burden.

I understand the problem but you're effectively asking we would always
do this going forward too :/.

> It is also very hard to modify the crate fetcher without actually modifying 
> OE-Core. At least I find my Python-fu lacking in regards to how I can
> monkeypatch the fetcher to use a modified version of
> On the other, it is trivial for you to backport this patch to the two
> branches in OE-Core. And as long as the second patch in the series (which 
> requires that checksums are used) is not backported, I cannot see that it 
> should have any negative impact.

This change alone is fine. The behaviour where people expect older
layers to always work with newer code changes is what worries me, a
lot. We have done things to make this happen before and I'm not sure it
is good to continue the expectation.



  reply	other threads:[~2023-04-06 11:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17  8:19 [bitbake-devel][PATCH v2 1/3] fetch2: Add checksum capability for crate fetcher frederic.martinsons
2023-03-17  8:19 ` [bitbake-devel][PATCH v2 2/3] make checksum verification mandatory frederic.martinsons
2023-03-17  8:19 ` [bitbake-devel][PATCH v2 3/3] authorize crate url with parameters frederic.martinsons
2023-04-06  3:40   ` Peter Kjellerstedt
2023-04-06  8:42     ` Richard Purdie
2023-04-06 10:56       ` Peter Kjellerstedt
2023-04-06 11:12         ` Richard Purdie [this message]
2023-03-21 17:02 ` [bitbake-devel][PATCH v2 1/3] fetch2: Add checksum capability for crate fetcher Frédéric Martinsons
2023-03-21 17:26   ` Frédéric Martinsons
2023-03-21 18:34     ` Alexander Kanavin
2023-03-21 19:51       ` Frédéric Martinsons

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:

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

  git send-email \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).