bitbake-devel.lists.openembedded.org archive mirror
 help / color / mirror / Atom feed
From: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	Steve Sakoman <steve@sakoman.com>
Cc: Frederic Martinsons <frederic.martinsons@gmail.com>,
	"bitbake-devel@lists.openembedded.org"
	<bitbake-devel@lists.openembedded.org>
Subject: RE: [bitbake-devel][PATCH v2 3/3] crate.py: authorize crate url with parameters
Date: Thu, 6 Apr 2023 10:56:53 +0000	[thread overview]
Message-ID: <DB5PR02MB10213AA7D4BB051D113ED80A5EF919@DB5PR02MB10213.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <37f0b57bb3fc25c4232378f94fb8d30929c53e6d.camel@linuxfoundation.org>

> -----Original Message-----
> From: Richard Purdie <richard.purdie@linuxfoundation.org>
> Sent: den 6 april 2023 10:43
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; Steve Sakoman
> <steve@sakoman.com>
> Cc: Frederic Martinsons <frederic.martinsons@gmail.com>; bitbake-
> devel@lists.openembedded.org
> 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 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.

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.

> 
> Cheers,
> 
> Richard

//Peter


  reply	other threads:[~2023-04-06 10:57 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 [this message]
2023-04-06 11:12         ` Richard Purdie
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:
  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=DB5PR02MB10213AA7D4BB051D113ED80A5EF919@DB5PR02MB10213.eurprd02.prod.outlook.com \
    --to=peter.kjellerstedt@axis.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=frederic.martinsons@gmail.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=steve@sakoman.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 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).