[PATCH] bmaptool: Add bmap-tools alias for compatibility

[PATCH] bmaptool: Add bmap-tools alias for compatibility

[Tom Hochstein]

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(+)

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"
-- 
2.25.1

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Richard Purdie]

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

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

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.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 1904 bytes --]

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Alexander Kanavin]

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

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Richard Purdie]

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

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

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.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 2588 bytes --]

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Richard Purdie]

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

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

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.


-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

[-- Attachment #2: Type: text/html, Size: 1072 bytes --]

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Alexander Kanavin]

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

Re: [OE-core] [PATCH] bmaptool: Add bmap-tools alias for compatibility

[Tim Orling]

[-- Attachment #1: Type: text/plain, Size: 2205 bytes --]

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]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

[-- Attachment #2: Type: text/html, Size: 3414 bytes --]