Re: [PATCH v2 0/3] u-boot regression fix, cleanup restoration

[Henning Schild <henning.schild@siemens.com>]

Am Mon, 26 Nov 2018 12:08:47 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 26.11.18 11:16, Henning Schild wrote:
> > Am Mon, 26 Nov 2018 10:49:53 +0100
> > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >   
> >> On 26.11.18 10:47, Henning Schild wrote:  
> >>> Did you try putting MACHINE into PV and pinning on that? It is
> >>> always the same package and multiple versions are .... multiple
> >>> versions.  
> >>
> >> That won't fly. We want recipes to generate results that be be
> >> exchanged (u-boot-myboard either from u-boot mainline or from some
> >> vendor recipe).  
> > 
> > Could you explain the problem in more detail? I do not understand
> > the issue yet. I know the pattern comes from multiconfig conflicts
> > you have found in jailhouse-images ... but messing with PN at
> > runtime just sounds like a very bad idea. I am not surprised that
> > uncovered a bitbake bug ....  
> 
> This recipe is not messing with PN, neither before not after your
> patch. It is just defining its output package names independently of
> the PN. E.g., we have u-boot_xxx.bb as recipe to build packages from
> upstream U-Boot sources. Those shall carry the same, stable names as
> package built by some u-boot-downstream_xxx.bb which use a downstream
> source repo. That allows to switch providers by just defining
> PREFERRED_PROVIDER_u-boot-<machine>. Your patch would enforce to
> change also all recipes that pull that target. That's not desirable
> (and broke jailhouse-images as a pioneer user).

I still did not get all of it but the kernel is actually an example of
debian doing the same upstream. They add configuration strings to the
package name and do not distinguish multiple kernels by package version.
So i guess it is fair to do the same for the bootloader.

Henning

> Jan
>