From: Richard Purdie <firstname.lastname@example.org>
To: Peter Kjellerstedt <email@example.com>,
Steve Sakoman <firstname.lastname@example.org>
Cc: Frederic Martinsons <email@example.com>,
Subject: Re: [bitbake-devel][PATCH v2 3/3] crate.py: authorize crate url with parameters
Date: Thu, 06 Apr 2023 12:12:49 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Thu, 2023-04-06 at 10:56 +0000, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From: Richard Purdie <email@example.com>
> > Sent: den 6 april 2023 10:43
> > To: Peter Kjellerstedt <firstname.lastname@example.org>; Steve Sakoman
> > <email@example.com>
> > Cc: Frederic Martinsons <firstname.lastname@example.org>; bitbake-
> > email@example.com
> > Subject: Re: [bitbake-devel][PATCH v2 3/3] crate.py: 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 crates.inc 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 crate.py.
> 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.
next prev parent 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] crate.py: make checksum verification mandatory frederic.martinsons
2023-03-17 8:19 ` [bitbake-devel][PATCH v2 3/3] crate.py: 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
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).