| Message ID | 20240305203608.3039688-1-tom.hochstein@nxp.com |
|---|---|
| State | New |
| Headers | show |
| Series | bmaptool: Add bmap-tools alias for compatibility | expand |
On Tue, 2024-03-05 at 14:36 -0600, Tom Hochstein wrote: > The rename of bmap-tools to bmaptool creates an incompatibility for > pre-scarthgap layers. Restore compatibility by adding bmap-tools as > an alias. > > Acked-by: Otavio Salvador <otavio@ossystems.com.br> > Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com> > --- > meta/recipes-support/bmaptool/bmaptool_git.bb | 8 ++++++++ > 1 file changed, 8 insertions(+) Perhaps we should just drop nanbield from the layer series instead as we're about to do that anyway? I'm worried this will just mask things and stop people renaming :/. Cheers, Richard
Em ter., 5 de mar. de 2024 às 21:06, Richard Purdie < richard.purdie@linuxfoundation.org> escreveu: > On Tue, 2024-03-05 at 14:36 -0600, Tom Hochstein wrote: > > The rename of bmap-tools to bmaptool creates an incompatibility for > > pre-scarthgap layers. Restore compatibility by adding bmap-tools as > > an alias. > > > > Acked-by: Otavio Salvador <otavio@ossystems.com.br> > > Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com> > > --- > > meta/recipes-support/bmaptool/bmaptool_git.bb | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > Perhaps we should just drop nanbield from the layer series instead as > we're about to do that anyway? > > I'm worried this will just mask things and stop people renaming :/. > I understand your point of view, but it is a must for package feeds, or it will break them.
On Wed, 6 Mar 2024 at 13:13, Otavio Salvador <otavio.salvador@ossystems.com.br> wrote: >> I'm worried this will just mask things and stop people renaming :/. > > > I understand your point of view, but it is a must for package feeds, or it will break them. For that purpose just RREPLACES/RCONFLICTS can be kept, and the rest dropped from the patch? Alex
On Wed, 2024-03-06 at 09:13 -0300, Otavio Salvador wrote: > > > Em ter., 5 de mar. de 2024 às 21:06, Richard Purdie > <richard.purdie@linuxfoundation.org> escreveu: > > On Tue, 2024-03-05 at 14:36 -0600, Tom Hochstein wrote: > > > The rename of bmap-tools to bmaptool creates an incompatibility > > > for > > > pre-scarthgap layers. Restore compatibility by adding bmap-tools > > > as > > > an alias. > > > > > > Acked-by: Otavio Salvador <otavio@ossystems.com.br> > > > Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com> > > > --- > > > meta/recipes-support/bmaptool/bmaptool_git.bb | 8 ++++++++ > > > 1 file changed, 8 insertions(+) > > > > Perhaps we should just drop nanbield from the layer series instead > > as > > we're about to do that anyway? > > > > I'm worried this will just mask things and stop people renaming :/. > > > > > I understand your point of view, but it is a must for package feeds, > or it will break them. You need the R* changes for that which is fair enough but you do not the PROVIDES... Cheers, Richard
Em qua., 6 de mar. de 2024 às 09:36, Richard Purdie < richard.purdie@linuxfoundation.org> escreveu: > On Wed, 2024-03-06 at 09:13 -0300, Otavio Salvador wrote: > > Em ter., 5 de mar. de 2024 às 21:06, Richard Purdie > > <richard.purdie@linuxfoundation.org> escreveu: > > > On Tue, 2024-03-05 at 14:36 -0600, Tom Hochstein wrote: > > > > The rename of bmap-tools to bmaptool creates an incompatibility > > > > for > > > > pre-scarthgap layers. Restore compatibility by adding bmap-tools > > > > as > > > > an alias. > > > > > > > > Acked-by: Otavio Salvador <otavio@ossystems.com.br> > > > > Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com> > > > > --- > > > > meta/recipes-support/bmaptool/bmaptool_git.bb | 8 ++++++++ > > > > 1 file changed, 8 insertions(+) > > > > > > Perhaps we should just drop nanbield from the layer series instead > > > as > > > we're about to do that anyway? > > > > > > I'm worried this will just mask things and stop people renaming :/. > > > > > > > I understand your point of view, but it is a must for package feeds, > > or it will break them. > > You need the R* changes for that which is fair enough but you do not > the PROVIDES... > Sure, but since we're late on release, it would be helpful to maintain compatibility.
On Wed, 2024-03-06 at 09:48 -0300, Otavio Salvador wrote: > > > Em qua., 6 de mar. de 2024 às 09:36, Richard Purdie > <richard.purdie@linuxfoundation.org> escreveu: > > On Wed, 2024-03-06 at 09:13 -0300, Otavio Salvador wrote: > > > Em ter., 5 de mar. de 2024 às 21:06, Richard Purdie > > > <richard.purdie@linuxfoundation.org> escreveu: > > > > On Tue, 2024-03-05 at 14:36 -0600, Tom Hochstein wrote: > > > > > The rename of bmap-tools to bmaptool creates an > > > > > incompatibility > > > > > for > > > > > pre-scarthgap layers. Restore compatibility by adding bmap- > > > > > tools > > > > > as > > > > > an alias. > > > > > > > > > > Acked-by: Otavio Salvador <otavio@ossystems.com.br> > > > > > Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com> > > > > > --- > > > > > meta/recipes-support/bmaptool/bmaptool_git.bb | 8 ++++++++ > > > > > 1 file changed, 8 insertions(+) > > > > > > > > Perhaps we should just drop nanbield from the layer series > > > > instead > > > > as > > > > we're about to do that anyway? > > > > > > > > I'm worried this will just mask things and stop people renaming > > > > :/. > > > > > > > > > > I understand your point of view, but it is a must for package > > > feeds, > > > or it will break them. > > > > You need the R* changes for that which is fair enough but you do > > not > > the PROVIDES... > > Sure, but since we're late on release, it would be helpful to > maintain compatibility. You mean make it easier for people to have one layer that works with multiple project releases? Is that something we really want to encourage? As I said, my concern is that people will simply ignore the rename if we merge that patch rather than fix their metadata. At that point we'll basically end up having to live with the mix of old and new names forever and users will get confused. Put another way, if I were to merge the PROVIDES, when would it ever be acceptable to remove it? Cheers, Richard
Em qua., 6 de mar. de 2024 às 09:55, Richard Purdie < richard.purdie@linuxfoundation.org> escreveu: > 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.
On Wed, 6 Mar 2024 at 14:08, Otavio Salvador <otavio.salvador@ossystems.com.br> 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. Alex
On Wed, Mar 6, 2024 at 7:04 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > On Wed, 6 Mar 2024 at 14:08, Otavio Salvador > <otavio.salvador@ossystems.com.br> 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 (#196681): > https://lists.openembedded.org/g/openembedded-core/message/196681 > Mute This Topic: https://lists.openembedded.org/mt/104753355/924729 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > ticotimo@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
diff --git a/meta/recipes-support/bmaptool/bmaptool_git.bb b/meta/recipes-support/bmaptool/bmaptool_git.bb index 87328af8c6..33f46d7070 100644 --- a/meta/recipes-support/bmaptool/bmaptool_git.bb +++ b/meta/recipes-support/bmaptool/bmaptool_git.bb @@ -9,6 +9,9 @@ SECTION = "console/utils" LICENSE = "GPL-2.0-only" LIC_FILES_CHKSUM = "file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263" +# For compatibility with layers before scarthgap +PROVIDES += "bmap-tools" + FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI = "git://github.com/yoctoproject/${BPN};branch=main;protocol=https \ file://0001-BmapCopy.py-fix-error-message.patch \ @@ -28,4 +31,9 @@ RDEPENDS:${PN} = "python3-core python3-compression python3-misc python3-mmap pyt inherit setuptools3 +# For compatibility with layers before scarthgap +RPROVIDES:${PN} = "bmap-tools" +RREPLACES:${PN} = "bmap-tools" +RCONFLICTS:${PN} = "bmap-tools" + BBCLASSEXTEND = "native nativesdk"