On Wed, Mar 6, 2024 at 7:04 AM Alexander Kanavin <[email protected]>
wrote:

> On Wed, 6 Mar 2024 at 14:08, Otavio Salvador
> <[email protected]> wrote:
> >> Put another way, if I were to merge the PROVIDES, when would it ever be
> >> acceptable to remove it?
> >
> >
> > I'd do it in next release; so it keeps a time for upgrade.
>
> But what would incentivize people to fix the metadata? If you put
> PROVIDES in there, they are not going to notice that they have to fix
> anything, and when it's removed later, it will break all the same.
> What's the point of this additional work then?
>
> It's master branch, it can and does break. No one ever promised that
> you can make a layer that works across several releases, and I would
> strongly object to making such a promise.
>

As one of the new maintainers for bmaptool, I was somewhat leaning towards
the old name, but that ship has sailed.
As Alex points out, change happens in master. This is normal. This should
not be prevented nor should workarounds
to let users continue to follow now "wrong" practices continue.

I will also chime in to say that layers that claim multiple
LAYERSERIES_COMPAT are really a problem for the layerindex.
The existing update mechanism is driven by well behaved stable branch
names. Anything else requires manual intervention.

This means that layers that do not follow stable branch names will not
automatically be installed with something like:
bitbake-layers layerindex-fetch
which is really a shame because that tool is much easier for users (and
likely to be part of upcoming bitbake/oe-core setup behavior).

Branches are cheap. CI can push to multiple branches with the same content.


> Alex
>
> 
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196759): 
https://lists.openembedded.org/g/openembedded-core/message/196759
Mute This Topic: https://lists.openembedded.org/mt/104753355/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to