Re: [bitbake-devel][PATCH v2 3/3] crate.py: authorize crate url with parameters

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2023-04-06 at 10:56 +0000, Peter Kjellerstedt wrote:
> > -----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 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.

Cheers,

Richard