[Buildroot] [PATCH 0/4 v2] package/pkg-golang: simplify installing multiple binaries

[Buildroot] [PATCH 0/4 v2] package/pkg-golang: simplify installing multiple binaries

[yann.morin]

From: "Yann E. MORIN" <yann.morin@orange.com>

Hello All!

This small series aims at simplifying the golang-package infra when a
package builds multiple targets and thus installs multiple binaries.

Changes v1 -> v2:
  - account for distribution-registry, package added since v1 was posted


Regards,
Yann E. MORIN.


The following changes since commit 901b9e19ed3741d0cc379ff8f145b2294a3bd09b

  package/kvmtool: fix build failure w/ musl (2025-06-30 22:20:31 +0200)


are available as patches in this mail series,

for you to apply patches up to 71793243b832c0c9f397911ce0bdf08e03f660b4

  package/pkg-golang: catch use of legacy FOO_INSTALL_BINS (2025-07-01 15:43:33 +0200)


----------------------------------------------------------------
Yann E. MORIN (4):
      package/pkg-golang: simplify installing multiple binaries
      package: drop default _INSTALL_BINS in golang-package
      package/cni-plugin: simplify installation
      package/pkg-golang: catch use of legacy FOO_INSTALL_BINS

 docs/manual/adding-packages-golang.adoc            | 26 +++++++++++-----------
 docs/manual/migrating.adoc                         |  5 +++++
 .../amazon-ecr-credential-helper.mk                |  1 -
 package/cni-plugins/cni-plugins.mk                 |  7 +++---
 package/containerd/containerd.mk                   |  1 -
 package/delve/delve.mk                             |  2 --
 .../distribution-registry/distribution-registry.mk |  1 -
 package/docker-cli/docker-cli.mk                   |  2 --
 package/docker-engine/docker-engine.mk             |  2 --
 package/mender-artifact/mender-artifact.mk         |  3 ---
 package/moby-buildkit/moby-buildkit.mk             |  4 ----
 package/pkg-golang.mk                              | 17 ++++++++++++--
 package/tailscale/tailscale.mk                     |  1 -
 13 files changed, 36 insertions(+), 36 deletions(-)

--
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[yann.morin]

From: "Yann E. MORIN" <yann.morin@orange.com>

Currently, when a golang package defines multiple _BUILD_TARGETS, it has
to basically repeat the same list in its _INSTALL_BINS.

When a golang package defines multiple _BUILD_TARGETS, the pkg-golang
infra will forcibly use the basename (the notdir) of each target as the
name of the generated binary; there is no option to set a per-target
binary name.

However, the pkg-golang infra by default tries to install a binary named
after the package rawname. This forces packages to basically repeat the
same list as their _BUILD_TARGETS to override _INSTALL_BINS, when the
list of generated binaries is already known to the infra.

We change the pkg-golang infra to better cover such a case:

  - if _BUILD_TARGET is '.' (the default), keep the current scheme:
    install a single binary named after the package rwaname;

  - if _BUILD_TARGET is not '.', and contains a single word, use the
    notdir of the built target, but allow the user to override it with
    _BIN_NAME (the current behaviour);

  - otherwise (_BUILD_TARGETS is set to more than one word), do not
    allow the user to set _BIN_NAME (it does not make sense), but set
    _INSTALL_BINS by default to the notdir of _BUILD_TARGETS.

We still allow the user to set _INSTALL_BINS in the last case, to cover
the case for existing packages; those are going to be "fixed" in the
following commits.

We now consider that _INSTALL_BINS is an internal implementation details
that should no longer be exposed to the users, so we drop it from the
documentation; we rephrase the corresponding part for _BUILD_TARGETS.

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Christian Stewart <christian@aperture.us>
---
 docs/manual/adding-packages-golang.adoc | 26 ++++++++++++-------------
 package/pkg-golang.mk                   | 11 +++++++++--
 2 files changed, 22 insertions(+), 15 deletions(-)

diff --git a/docs/manual/adding-packages-golang.adoc b/docs/manual/adding-packages-golang.adoc
index 6de0916a83..21b6a122a9 100644
--- a/docs/manual/adding-packages-golang.adoc
+++ b/docs/manual/adding-packages-golang.adoc
@@ -94,20 +94,20 @@ therefore only use a few of them, or none.
   defaults to +.+. We then have two cases:
 
 ** +FOO_BUILD_TARGETS+ is +.+. In this case, we assume only one binary
-   will be produced, and that by default we name it after the package
-   name. If that is not appropriate, the name of the produced binary
-   can be overridden using +FOO_BIN_NAME+.
+   will be built and installed, and by default we name it after the
+   package name; if that is not appropriate, the name of the binary can
+   be overridden using +FOO_BIN_NAME+.
 
-** +FOO_BUILD_TARGETS+ is not +.+. In this case, we iterate over the
-   values to build each target, and for each produced a binary that is
-   the non-directory component of the target. For example if
-   +FOO_BUILD_TARGETS = cmd/docker cmd/dockerd+ the binaries produced
-   are +docker+ and +dockerd+.
-
-* +FOO_INSTALL_BINS+ can be used to pass the list of binaries that
-  should be installed in +/usr/bin+ on the target. If
-  +FOO_INSTALL_BINS+ is not specified, it defaults to the lower-case
-  name of package.
+** +FOO_BUILD_TARGETS+ is not +.+. In this case, it is interpreted as a
+   space-separated list, and we iterate over the targets to build and
+   install a binary named after the non-directory component of the
+   target. For example if +FOO_BUILD_TARGETS = cmd/docker cmd/dockerd+,
+   the binaries built and installed are +docker+ and +dockerd+. If
+   +FOO_BUILD_TARGETS+ contains only one target, then it is possible to
+   override the built and installed binary by setting +FOO_BIN_NAME+,
+   as above; if +FOO_BUILD_TARGETS+ contains two or more targets, then
+   it is not possible to override the names of the installed binaries
+   (use a post-install hook for that).
 
 With the Go infrastructure, all the steps required to build and
 install the packages are already defined, and they generally work well
diff --git a/package/pkg-golang.mk b/package/pkg-golang.mk
index a4e8bd30cc..ff8d28aa7e 100644
--- a/package/pkg-golang.mk
+++ b/package/pkg-golang.mk
@@ -61,9 +61,16 @@ $(2)_BUILD_TARGETS ?= .
 # after each build target building them (below in <pkg>_BUILD_CMDS).
 ifeq ($$($(2)_BUILD_TARGETS),.)
 $(2)_BIN_NAME ?= $$($(2)_RAWNAME)
+$(2)_INSTALL_BINS ?= $$($(2)_BIN_NAME)
+else ifeq ($$(words $$($(2)_BUILD_TARGETS)),1)
+$(2)_BIN_NAME ?= $$(notdir $$($(2)_BUILD_TARGETS))
+$(2)_INSTALL_BINS ?= $$($(2)_BIN_NAME)
+else
+ifneq ($$($(2)_BIN_NAME),)
+$$(error $(1) sets $(2)_BIN_NAME while there are multiple targets in $(2)_BUILD_TARGETS)
+endif
+$(2)_INSTALL_BINS ?= $$(notdir $$($(2)_BUILD_TARGETS))
 endif
-
-$(2)_INSTALL_BINS ?= $$($(2)_RAWNAME)
 
 # Source files in Go usually use an import path resolved around
 # domain/vendor/software. We infer domain/vendor/software from the upstream URL
-- 
2.34.1

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[Romain Naour via buildroot]

Hello Yann, All,

Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
> From: "Yann E. MORIN" <yann.morin@orange.com>
> 
> Currently, when a golang package defines multiple _BUILD_TARGETS, it has
> to basically repeat the same list in its _INSTALL_BINS.
> 
> When a golang package defines multiple _BUILD_TARGETS, the pkg-golang
> infra will forcibly use the basename (the notdir) of each target as the
> name of the generated binary; there is no option to set a per-target
> binary name.
> 
> However, the pkg-golang infra by default tries to install a binary named
> after the package rawname. This forces packages to basically repeat the
> same list as their _BUILD_TARGETS to override _INSTALL_BINS, when the
> list of generated binaries is already known to the infra.
> 
> We change the pkg-golang infra to better cover such a case:
> 
>   - if _BUILD_TARGET is '.' (the default), keep the current scheme:
>     install a single binary named after the package rwaname;
> 
>   - if _BUILD_TARGET is not '.', and contains a single word, use the
>     notdir of the built target, but allow the user to override it with
>     _BIN_NAME (the current behaviour);
> 
>   - otherwise (_BUILD_TARGETS is set to more than one word), do not
>     allow the user to set _BIN_NAME (it does not make sense), but set
>     _INSTALL_BINS by default to the notdir of _BUILD_TARGETS.
> 
> We still allow the user to set _INSTALL_BINS in the last case, to cover
> the case for existing packages; those are going to be "fixed" in the
> following commits.
> 
> We now consider that _INSTALL_BINS is an internal implementation details
> that should no longer be exposed to the users, so we drop it from the
> documentation; we rephrase the corresponding part for _BUILD_TARGETS.
> 
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Christian Stewart <christian@aperture.us>

Reviewed-by: Romain Naour <romain.naour@smile.fr>

Since it's about a package infrastucture change, I prefer wait for a second review.

> ---
>  docs/manual/adding-packages-golang.adoc | 26 ++++++++++++-------------
>  package/pkg-golang.mk                   | 11 +++++++++--
>  2 files changed, 22 insertions(+), 15 deletions(-)
> 
> diff --git a/docs/manual/adding-packages-golang.adoc b/docs/manual/adding-packages-golang.adoc
> index 6de0916a83..21b6a122a9 100644
> --- a/docs/manual/adding-packages-golang.adoc
> +++ b/docs/manual/adding-packages-golang.adoc
> @@ -94,20 +94,20 @@ therefore only use a few of them, or none.
>    defaults to +.+. We then have two cases:
>  
>  ** +FOO_BUILD_TARGETS+ is +.+. In this case, we assume only one binary
> -   will be produced, and that by default we name it after the package
> -   name. If that is not appropriate, the name of the produced binary
> -   can be overridden using +FOO_BIN_NAME+.
> +   will be built and installed, and by default we name it after the
> +   package name; if that is not appropriate, the name of the binary can
> +   be overridden using +FOO_BIN_NAME+.
>  
> -** +FOO_BUILD_TARGETS+ is not +.+. In this case, we iterate over the
> -   values to build each target, and for each produced a binary that is
> -   the non-directory component of the target. For example if
> -   +FOO_BUILD_TARGETS = cmd/docker cmd/dockerd+ the binaries produced
> -   are +docker+ and +dockerd+.
> -
> -* +FOO_INSTALL_BINS+ can be used to pass the list of binaries that
> -  should be installed in +/usr/bin+ on the target. If
> -  +FOO_INSTALL_BINS+ is not specified, it defaults to the lower-case
> -  name of package.
> +** +FOO_BUILD_TARGETS+ is not +.+. In this case, it is interpreted as a
> +   space-separated list, and we iterate over the targets to build and
> +   install a binary named after the non-directory component of the
> +   target. For example if +FOO_BUILD_TARGETS = cmd/docker cmd/dockerd+,
> +   the binaries built and installed are +docker+ and +dockerd+. If
> +   +FOO_BUILD_TARGETS+ contains only one target, then it is possible to
> +   override the built and installed binary by setting +FOO_BIN_NAME+,
> +   as above; if +FOO_BUILD_TARGETS+ contains two or more targets, then
> +   it is not possible to override the names of the installed binaries
> +   (use a post-install hook for that).
>  
>  With the Go infrastructure, all the steps required to build and
>  install the packages are already defined, and they generally work well
> diff --git a/package/pkg-golang.mk b/package/pkg-golang.mk
> index a4e8bd30cc..ff8d28aa7e 100644
> --- a/package/pkg-golang.mk
> +++ b/package/pkg-golang.mk
> @@ -61,9 +61,16 @@ $(2)_BUILD_TARGETS ?= .
>  # after each build target building them (below in <pkg>_BUILD_CMDS).
>  ifeq ($$($(2)_BUILD_TARGETS),.)
>  $(2)_BIN_NAME ?= $$($(2)_RAWNAME)
> +$(2)_INSTALL_BINS ?= $$($(2)_BIN_NAME)
> +else ifeq ($$(words $$($(2)_BUILD_TARGETS)),1)
> +$(2)_BIN_NAME ?= $$(notdir $$($(2)_BUILD_TARGETS))
> +$(2)_INSTALL_BINS ?= $$($(2)_BIN_NAME)
> +else
> +ifneq ($$($(2)_BIN_NAME),)
> +$$(error $(1) sets $(2)_BIN_NAME while there are multiple targets in $(2)_BUILD_TARGETS)
> +endif
> +$(2)_INSTALL_BINS ?= $$(notdir $$($(2)_BUILD_TARGETS))
>  endif

Is our testsuite is testing each use case?

Best regards,
Romain

> -
> -$(2)_INSTALL_BINS ?= $$($(2)_RAWNAME)
>  
>  # Source files in Go usually use an import path resolved around
>  # domain/vendor/software. We infer domain/vendor/software from the upstream URL

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[Christian Stewart via buildroot]

Hi Yann, Romain, All,


On Sat, Jul 5, 2025 at 1:51 PM Romain Naour <romain.naour@smile.fr> wrote:
> Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
> >
> > We change the pkg-golang infra to better cover such a case:
> >
> >   - if _BUILD_TARGET is '.' (the default), keep the current scheme:
> >     install a single binary named after the package rwaname;
> >
> >   - if _BUILD_TARGET is not '.', and contains a single word, use the
> >     notdir of the built target, but allow the user to override it with
> >     _BIN_NAME (the current behaviour);
> >
> >   - otherwise (_BUILD_TARGETS is set to more than one word), do not
> >     allow the user to set _BIN_NAME (it does not make sense), but set
> >     _INSTALL_BINS by default to the notdir of _BUILD_TARGETS.

This looks great to me. It's just improving the default cases. We can
still override _INSTALL_BINS.

> > We still allow the user to set _INSTALL_BINS in the last case, to cover
> > the case for existing packages; those are going to be "fixed" in the
> > following commits.

> > We now consider that _INSTALL_BINS is an internal implementation details
> > that should no longer be exposed to the users, so we drop it from the
> > documentation; we rephrase the corresponding part for _BUILD_TARGETS.

Is there any case where we would still want to override this? I guess
the logic is we would never bother building a binary if we don't
install it. This makes sense to me but I don't think of any exceptions
at the moment. I haven't touched this in so long so I don't know for
sure.

I will go ahead and test this series on my end.

Reviewed-by: Christian Stewart <christian@aperture.us>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[yann.morin]

Christian, All,

On 2025-07-06 15:06 -0700, Christian Stewart spake thusly:
> On Sat, Jul 5, 2025 at 1:51 PM Romain Naour <romain.naour@smile.fr> wrote:
> > Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
[--SNIP--]
> > > We now consider that _INSTALL_BINS is an internal implementation details
> > > that should no longer be exposed to the users, so we drop it from the
> > > documentation; we rephrase the corresponding part for _BUILD_TARGETS.
> Is there any case where we would still want to override this?

The thing is that, in the case of multiple _BUILD_TARGETS, theinfra
generates executables based on the basename of each _BUILD_TARGETS; as
the example in the doc describes; for example, given:
    FOO_BUILD_TARGETS = cmd/docker cmd/dockerd

then the generated executables are "docker" and "dockerd".

So, if we allow setting _INSTALL_BINS to an arbitrary list, it can
easily get out of sync with the list in _BUILD_TARGETS. And there is
also no way to set the name of the generated executable for each entry
in _BUILD_TARGETS...

So, it does not make sense to keep _INSTALL_BINS settable (see the last
patch in the series).

> I guess
> the logic is we would never bother building a binary if we don't
> install it.

Exactly: if you don't want it installed, don't build it. ;-)

If the package has optional binaries, they can just be conditionally
added to _BUILD_TARGETS just as we do it for any kind of package
infra.

> This makes sense to me but I don't think of any exceptions
> at the moment. I haven't touched this in so long so I don't know for
> sure.

Eh, I know the feeling. ;-)

> I will go ahead and test this series on my end.
> Reviewed-by: Christian Stewart <christian@aperture.us>

Thanks for the feedback! 👍

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[yann.morin]

Romain, All,

On 2025-07-05 22:51 +0200, Romain Naour spake thusly:
> Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
> > From: "Yann E. MORIN" <yann.morin@orange.com>
> > Currently, when a golang package defines multiple _BUILD_TARGETS, it has
> > to basically repeat the same list in its _INSTALL_BINS.
Nicolas BUFFON <nicolas.buffon@orange.com> > 
> > Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> > Cc: Christian Stewart <christian@aperture.us>
> Reviewed-by: Romain Naour <romain.naour@smile.fr>
> Since it's about a package infrastucture change, I prefer wait for a second review.

Thanks for the review!

[--SNIP--]
> > diff --git a/package/pkg-golang.mk b/package/pkg-golang.mk
> > index a4e8bd30cc..ff8d28aa7e 100644
> > --- a/package/pkg-golang.mk
> > +++ b/package/pkg-golang.mk
> > @@ -61,9 +61,16 @@ $(2)_BUILD_TARGETS ?= .
> >  # after each build target building them (below in <pkg>_BUILD_CMDS).
> >  ifeq ($$($(2)_BUILD_TARGETS),.)
> >  $(2)_BIN_NAME ?= $$($(2)_RAWNAME)
> > +$(2)_INSTALL_BINS ?= $$($(2)_BIN_NAME)
> > +else ifeq ($$(words $$($(2)_BUILD_TARGETS)),1)
> > +$(2)_BIN_NAME ?= $$(notdir $$($(2)_BUILD_TARGETS))
> > +$(2)_INSTALL_BINS ?= $$($(2)_BIN_NAME)
> > +else
> > +ifneq ($$($(2)_BIN_NAME),)
> > +$$(error $(1) sets $(2)_BIN_NAME while there are multiple targets in $(2)_BUILD_TARGETS)
> > +endif
> > +$(2)_INSTALL_BINS ?= $$(notdir $$($(2)_BUILD_TARGETS))
> >  endif
> 
> Is our testsuite is testing each use case?

Depends: do we have at least one package to cover each case? ;-)

I'll try to dig that in the coming days.

Thanks for the feedback. :-)

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[yann.morin]

Romain, All,

On 2025-07-05 22:51 +0200, Romain Naour spake thusly:
> Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
> > From: "Yann E. MORIN" <yann.morin@orange.com>
> > Currently, when a golang package defines multiple _BUILD_TARGETS, it has
> > to basically repeat the same list in its _INSTALL_BINS.
[--SNIP--]
> > We now consider that _INSTALL_BINS is an internal implementation details
> > that should no longer be exposed to the users, so we drop it from the
> > documentation; we rephrase the corresponding part for _BUILD_TARGETS.
> > 
> > Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> > Cc: Christian Stewart <christian@aperture.us>
> Reviewed-by: Romain Naour <romain.naour@smile.fr>
> Since it's about a package infrastucture change, I prefer wait for a second review.

What about the status of this series? Christian has provided his
Reviewed-by a while back...

Regards,
Yann E. MORIN.

-- 

.-----------------.--------------------:̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅_̅ ̅̅̅̅ ̅̅̅̅ ̅̅̅̅ ̅:------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[Christian Stewart via buildroot]

[-- Attachment #1.1: Type: text/plain, Size: 1096 bytes --]

Hi Yann,

On Tue, Sep 9, 2025, 12:47 AM <yann.morin@orange.com> wrote:

> Romain, All,
>
> On 2025-07-05 22:51 +0200, Romain Naour spake thusly:
> > Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
> > > From: "Yann E. MORIN" <yann.morin@orange.com>
> > > Currently, when a golang package defines multiple _BUILD_TARGETS, it
> has
> > > to basically repeat the same list in its _INSTALL_BINS.
> [--SNIP--]
> > > We now consider that _INSTALL_BINS is an internal implementation
> details
> > > that should no longer be exposed to the users, so we drop it from the
> > > documentation; we rephrase the corresponding part for _BUILD_TARGETS.
> > >
> > > Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> > > Cc: Christian Stewart <christian@aperture.us>
> > Reviewed-by: Romain Naour <romain.naour@smile.fr>
> > Since it's about a package infrastucture change, I prefer wait for a
> second review.
>
> What about the status of this series? Christian has provided his
> Reviewed-by a while back...
>

It still looks good to me!

Best regards,
Christian

[-- Attachment #1.2: Type: text/html, Size: 2010 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[Romain Naour via buildroot]

Hello Yann, Christian, All,

Le 09/09/2025 à 19:56, Christian Stewart a écrit :
> Hi Yann,
> 
> On Tue, Sep 9, 2025, 12:47 AM <yann.morin@orange.com
> <mailto:yann.morin@orange.com>> wrote:
> 
>     Romain, All,
> 
>     On 2025-07-05 22:51 +0200, Romain Naour spake thusly:
>     > Le 01/07/2025 à 15:45, yann.morin@orange.com
>     <mailto:yann.morin@orange.com> a écrit :
>     > > From: "Yann E. MORIN" <yann.morin@orange.com <mailto:yann.morin@orange.com>>
>     > > Currently, when a golang package defines multiple _BUILD_TARGETS, it has
>     > > to basically repeat the same list in its _INSTALL_BINS.
>     [--SNIP--]
>     > > We now consider that _INSTALL_BINS is an internal implementation details
>     > > that should no longer be exposed to the users, so we drop it from the
>     > > documentation; we rephrase the corresponding part for _BUILD_TARGETS.
>     > >
>     > > Signed-off-by: Yann E. MORIN <yann.morin@orange.com
>     <mailto:yann.morin@orange.com>>
>     > > Cc: Christian Stewart <christian@aperture.us <mailto:christian@aperture.us>>
>     > Reviewed-by: Romain Naour <romain.naour@smile.fr
>     <mailto:romain.naour@smile.fr>>
>     > Since it's about a package infrastucture change, I prefer wait for a
>     second review.
> 
>     What about the status of this series? Christian has provided his
>     Reviewed-by a while back...
> 
> 
> It still looks good to me!

Thanks for the reminder!
Now the 2025.08 is release (and next merged in master), we can go ahead.

Btw, I replaced 2025.08 by 2025.11 in the last commit.

Applied to master, thanks.

Best regards,
Romain


> 
> Best regards,
> Christian

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[yann.morin]

Romain, All,

On 2025-09-10 13:19 +0200, Romain Naour spake thusly:
> Le 09/09/2025 à 19:56, Christian Stewart a écrit :
> > On Tue, Sep 9, 2025, 12:47 AM <yann.morin@orange.com
> > <mailto:yann.morin@orange.com>> wrote:
> > > What about the status of this series? Christian has provided his
> > > Reviewed-by a while back...
> > It still looks good to me!
> Thanks for the reminder!
> Now the 2025.08 is release (and next merged in master), we can go ahead.
> Btw, I replaced 2025.08 by 2025.11 in the last commit.

I might have been a little tiny weeny bit too optimistic. 😜

> Applied to master, thanks.

Thanks! 👍

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[Christian Stewart via buildroot]

Yann,

On Wed, Sep 10, 2025 at 4:41 AM <yann.morin@orange.com> wrote:
>
> Romain, All,
>
> On 2025-09-10 13:19 +0200, Romain Naour spake thusly:
> > Le 09/09/2025 à 19:56, Christian Stewart a écrit :
> > > On Tue, Sep 9, 2025, 12:47 AM <yann.morin@orange.com
> > > <mailto:yann.morin@orange.com>> wrote:
> > > > What about the status of this series? Christian has provided his
> > > > Reviewed-by a while back...
> > > It still looks good to me!
> > Thanks for the reminder!
> > Now the 2025.08 is release (and next merged in master), we can go ahead.
> > Btw, I replaced 2025.08 by 2025.11 in the last commit.
>
> I might have been a little tiny weeny bit too optimistic. 😜
>
> > Applied to master, thanks.

Now that this is merged, how do I rename a build binary before installing?

Here's an example:

https://github.com/skiffos/buildroot/blob/skiff/package/genuinetools-img/genuinetools-img.mk

Thanks,
Christian Stewart
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[Christian Stewart via buildroot]

hi Yann,

On Wed, Sep 10, 2025 at 12:07 PM Christian Stewart
<christian@aperture.us> wrote:
>
> Yann,
>
> On Wed, Sep 10, 2025 at 4:41 AM <yann.morin@orange.com> wrote:
> >
> > Romain, All,
> >
> > On 2025-09-10 13:19 +0200, Romain Naour spake thusly:
> > > Le 09/09/2025 à 19:56, Christian Stewart a écrit :
> > > > On Tue, Sep 9, 2025, 12:47 AM <yann.morin@orange.com
> > > > <mailto:yann.morin@orange.com>> wrote:
> > > > > What about the status of this series? Christian has provided his
> > > > > Reviewed-by a while back...
> > > > It still looks good to me!
> > > Thanks for the reminder!
> > > Now the 2025.08 is release (and next merged in master), we can go ahead.
> > > Btw, I replaced 2025.08 by 2025.11 in the last commit.
> >
> > I might have been a little tiny weeny bit too optimistic. 😜
> >
> > > Applied to master, thanks.
>
> Now that this is merged, how do I rename a build binary before installing?
>
> Here's an example:
>
> https://github.com/skiffos/buildroot/blob/skiff/package/genuinetools-img/genuinetools-img.mk

Oh, I guess we can still just set BIN_NAME. Ignore!

Thanks,
Christian
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 1/4 v2] package/pkg-golang: simplify installing multiple binaries

[yann.morin]

Christian, All,

On 2025-09-10 12:13 -0700, Christian Stewart spake thusly:
> On Wed, Sep 10, 2025 at 12:07 PM Christian Stewart
> <christian@aperture.us> wrote:
[--SNIP--]
> > Now that this is merged, how do I rename a build binary before installing?
> > Here's an example:
> > https://github.com/skiffos/buildroot/blob/skiff/package/genuinetools-img/genuinetools-img.mk
> Oh, I guess we can still just set BIN_NAME. Ignore!

 1. Yes, you can still set FOO_BIN_NAME when there is a single binary to
    install; quoting the manual:

    * FOO_BUILD_TARGETS is '.'. In this case, we assume only one binary
      will be built and installed, and by default we name it after the
      package name; if that is not appropriate, the name of the binary
      can be overridden using FOO_BIN_NAME.

    * FOO_BUILD_TARGETS is not '.'. In this case, it is interpreted as a
      space-separated list [...]. If FOO_BUILD_TARGETS contains only one
      target, then it is possible to override the built and installed
      binary by setting FOO_BIN_NAME, as above; [...]

 2. Unless I'm mistaken, the binary your package installs is named after
    the package, so you should not even need to specify it, as this is
    the default (and already was prior to this series); i.e. there
    should be no need for (the same way you did not specify it for the
    target variant):
        HOST_GENUINETOOLS_IMG_BIN_NAME = genuinetools-img

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/4 v2] package: drop default _INSTALL_BINS in golang-package

[yann.morin]

From: "Yann E. MORIN" <yann.morin@orange.com>

Now that the pkg-golang infra automatically sets _INSTALL_BINS by
default to the list of notdir of _BUILD_TARGETS, there is no need to do
that in packages anymore.

Most packages were already using the notdir construct, so those are
trivially fixed; a few had a hard-coded list that matched the built
targets list, so they too are trivially fixed.

host-mender-artifact was slightly different, in that it explicitly set
the _BIN_NAME to mender-artifact, which happens to be the default; it
also set _INSTALL_BINS to _BIN_NAME, so again using the default. This
package can also be fixed easily.

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com>
Cc: Christian Stewart <christian@aperture.us>
Cc: James Hilliard <james.hilliard1@gmail.com>

---
Changes v1 -> v2:
  - account for distribution-registry, new package added after v1 was
    posted
---
 .../amazon-ecr-credential-helper.mk                           | 1 -
 package/containerd/containerd.mk                              | 1 -
 package/delve/delve.mk                                        | 2 --
 package/distribution-registry/distribution-registry.mk        | 1 -
 package/docker-cli/docker-cli.mk                              | 2 --
 package/docker-engine/docker-engine.mk                        | 2 --
 package/mender-artifact/mender-artifact.mk                    | 3 ---
 package/moby-buildkit/moby-buildkit.mk                        | 4 ----
 package/tailscale/tailscale.mk                                | 1 -
 9 files changed, 17 deletions(-)

diff --git a/package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk b/package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk
index acfeea16fb..ad75ed3360 100644
--- a/package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk
+++ b/package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk
@@ -15,6 +15,5 @@ AMAZON_ECR_CREDENTIAL_HELPER_SUBDIR = ecr-login
 
 AMAZON_ECR_CREDENTIAL_HELPER_GOMOD = ./cli
 AMAZON_ECR_CREDENTIAL_HELPER_BUILD_TARGETS = docker-credential-ecr-login
-AMAZON_ECR_CREDENTIAL_HELPER_INSTALL_BINS = docker-credential-ecr-login
 
 $(eval $(golang-package))
diff --git a/package/containerd/containerd.mk b/package/containerd/containerd.mk
index 1f70a26ebf..2ef70ab5d7 100644
--- a/package/containerd/containerd.mk
+++ b/package/containerd/containerd.mk
@@ -20,7 +20,6 @@ CONTAINERD_BUILD_TARGETS = \
 	cmd/containerd-shim-runc-v2 \
 	cmd/ctr
 
-CONTAINERD_INSTALL_BINS = $(notdir $(CONTAINERD_BUILD_TARGETS))
 CONTAINERD_TAGS = no_aufs
 
 ifeq ($(BR2_PACKAGE_LIBAPPARMOR),y)
diff --git a/package/delve/delve.mk b/package/delve/delve.mk
index 408286e3b4..8206721fe2 100644
--- a/package/delve/delve.mk
+++ b/package/delve/delve.mk
@@ -12,11 +12,9 @@ DELVE_DEPENDENCIES = host-pkgconf
 
 DELVE_TAGS = cgo
 DELVE_BUILD_TARGETS = cmd/dlv
-DELVE_INSTALL_BINS = $(notdir $(DELVE_BUILD_TARGETS))
 
 HOST_DELVE_TAGS = cgo
 HOST_DELVE_BUILD_TARGETS = cmd/dlv
-HOST_DELVE_INSTALL_BINS = $(notdir $(HOST_DELVE_BUILD_TARGETS))
 
 $(eval $(golang-package))
 $(eval $(host-golang-package))
diff --git a/package/distribution-registry/distribution-registry.mk b/package/distribution-registry/distribution-registry.mk
index 901b9c40e5..a01a3c1710 100644
--- a/package/distribution-registry/distribution-registry.mk
+++ b/package/distribution-registry/distribution-registry.mk
@@ -18,7 +18,6 @@ DISTRIBUTION_REGISTRY_BUILD_TARGETS = cmd/registry
 # distribution-registry builds and installs the 'registry' executable, but
 # that name is a bit too generic. Rename it to match the package name.
 DISTRIBUTION_REGISTRY_BIN_NAME = distribution-registry
-DISTRIBUTION_REGISTRY_INSTALL_BINS = distribution-registry
 
 # Inject the version as if done by upstream's wrapper Makefile
 define DISTRIBUTION_REGISTRY_SET_VERSION
diff --git a/package/docker-cli/docker-cli.mk b/package/docker-cli/docker-cli.mk
index e118481838..7386b007cd 100644
--- a/package/docker-cli/docker-cli.mk
+++ b/package/docker-cli/docker-cli.mk
@@ -38,6 +38,4 @@ define DOCKER_CLI_FIX_VENDORING
 endef
 DOCKER_CLI_POST_EXTRACT_HOOKS += DOCKER_CLI_FIX_VENDORING
 
-DOCKER_CLI_INSTALL_BINS = $(notdir $(DOCKER_CLI_BUILD_TARGETS))
-
 $(eval $(golang-package))
diff --git a/package/docker-engine/docker-engine.mk b/package/docker-engine/docker-engine.mk
index c39dc2b440..181975b26b 100644
--- a/package/docker-engine/docker-engine.mk
+++ b/package/docker-engine/docker-engine.mk
@@ -70,8 +70,6 @@ define DOCKER_ENGINE_FIX_VENDORING
 endef
 DOCKER_ENGINE_POST_EXTRACT_HOOKS += DOCKER_ENGINE_FIX_VENDORING
 
-DOCKER_ENGINE_INSTALL_BINS = $(notdir $(DOCKER_ENGINE_BUILD_TARGETS))
-
 define DOCKER_ENGINE_INSTALL_INIT_SYSTEMD
 	$(INSTALL) -D -m 0644 $(@D)/contrib/init/systemd/docker.service \
 		$(TARGET_DIR)/usr/lib/systemd/system/docker.service
diff --git a/package/mender-artifact/mender-artifact.mk b/package/mender-artifact/mender-artifact.mk
index bcab91890a..7d6f0929e2 100644
--- a/package/mender-artifact/mender-artifact.mk
+++ b/package/mender-artifact/mender-artifact.mk
@@ -115,7 +115,4 @@ HOST_MENDER_ARTIFACT_GO_ENV += \
 
 HOST_MENDER_ARTIFACT_LDFLAGS = -X github.com/mendersoftware/mender-artifact/cli.Version=$(HOST_MENDER_ARTIFACT_VERSION)
 
-HOST_MENDER_ARTIFACT_BIN_NAME = mender-artifact
-HOST_MENDER_ARTIFACT_INSTALL_BINS = $(HOST_MENDER_ARTIFACT_BIN_NAME)
-
 $(eval $(host-golang-package))
diff --git a/package/moby-buildkit/moby-buildkit.mk b/package/moby-buildkit/moby-buildkit.mk
index 91560c1ed1..4ae1abde3a 100644
--- a/package/moby-buildkit/moby-buildkit.mk
+++ b/package/moby-buildkit/moby-buildkit.mk
@@ -17,12 +17,8 @@ MOBY_BUILDKIT_BUILD_TARGETS = cmd/buildctl cmd/buildkitd
 MOBY_BUILDKIT_LDFLAGS = \
 	-X $(MOBY_BUILDKIT_GOMOD)/version.Version="$(MOBY_BUILDKIT_VERSION)"
 
-MOBY_BUILDKIT_INSTALL_BINS = $(notdir $(MOBY_BUILDKIT_BUILD_TARGETS))
-
 HOST_MOBY_BUILDKIT_TAGS = cgo
 HOST_MOBY_BUILDKIT_BUILD_TARGETS = cmd/buildctl cmd/buildkitd
 
-HOST_MOBY_BUILDKIT_INSTALL_BINS = $(notdir $(HOST_MOBY_BUILDKIT_BUILD_TARGETS))
-
 $(eval $(golang-package))
 $(eval $(host-golang-package))
diff --git a/package/tailscale/tailscale.mk b/package/tailscale/tailscale.mk
index 7019b9afc9..8f25b0cbd1 100644
--- a/package/tailscale/tailscale.mk
+++ b/package/tailscale/tailscale.mk
@@ -10,7 +10,6 @@ TAILSCALE_LICENSE = BSD-3-Clause
 TAILSCALE_LICENSE_FILES = LICENSE
 TAILSCALE_GOMOD = tailscale.com
 TAILSCALE_BUILD_TARGETS = cmd/tailscale cmd/tailscaled
-TAILSCALE_INSTALL_BINS = tailscale tailscaled
 TAILSCALE_LDFLAGS = \
 	-X tailscale.com/version.longStamp=$(TAILSCALE_VERSION) \
 	-X tailscale.com/version.shortStamp=$(TAILSCALE_VERSION)
-- 
2.34.1

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 2/4 v2] package: drop default _INSTALL_BINS in golang-package

[Romain Naour via buildroot]

Hello Yann, All,

Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
> From: "Yann E. MORIN" <yann.morin@orange.com>
> 
> Now that the pkg-golang infra automatically sets _INSTALL_BINS by
> default to the list of notdir of _BUILD_TARGETS, there is no need to do
> that in packages anymore.
> 
> Most packages were already using the notdir construct, so those are
> trivially fixed; a few had a hard-coded list that matched the built
> targets list, so they too are trivially fixed.
> 
> host-mender-artifact was slightly different, in that it explicitly set
> the _BIN_NAME to mender-artifact, which happens to be the default; it
> also set _INSTALL_BINS to _BIN_NAME, so again using the default. This
> package can also be fixed easily.
> 
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Angelo Compagnucci <angelo.compagnucci@gmail.com>
> Cc: Christian Stewart <christian@aperture.us>
> Cc: James Hilliard <james.hilliard1@gmail.com>

Reviewed-by: Romain Naour <romain.naour@smile.fr>

Best regards,
Romain

> 
> ---
> Changes v1 -> v2:
>   - account for distribution-registry, new package added after v1 was
>     posted
> ---
>  .../amazon-ecr-credential-helper.mk                           | 1 -
>  package/containerd/containerd.mk                              | 1 -
>  package/delve/delve.mk                                        | 2 --
>  package/distribution-registry/distribution-registry.mk        | 1 -
>  package/docker-cli/docker-cli.mk                              | 2 --
>  package/docker-engine/docker-engine.mk                        | 2 --
>  package/mender-artifact/mender-artifact.mk                    | 3 ---
>  package/moby-buildkit/moby-buildkit.mk                        | 4 ----
>  package/tailscale/tailscale.mk                                | 1 -
>  9 files changed, 17 deletions(-)
> 
> diff --git a/package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk b/package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk
> index acfeea16fb..ad75ed3360 100644
> --- a/package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk
> +++ b/package/amazon-ecr-credential-helper/amazon-ecr-credential-helper.mk
> @@ -15,6 +15,5 @@ AMAZON_ECR_CREDENTIAL_HELPER_SUBDIR = ecr-login
>  
>  AMAZON_ECR_CREDENTIAL_HELPER_GOMOD = ./cli
>  AMAZON_ECR_CREDENTIAL_HELPER_BUILD_TARGETS = docker-credential-ecr-login
> -AMAZON_ECR_CREDENTIAL_HELPER_INSTALL_BINS = docker-credential-ecr-login
>  
>  $(eval $(golang-package))
> diff --git a/package/containerd/containerd.mk b/package/containerd/containerd.mk
> index 1f70a26ebf..2ef70ab5d7 100644
> --- a/package/containerd/containerd.mk
> +++ b/package/containerd/containerd.mk
> @@ -20,7 +20,6 @@ CONTAINERD_BUILD_TARGETS = \
>  	cmd/containerd-shim-runc-v2 \
>  	cmd/ctr
>  
> -CONTAINERD_INSTALL_BINS = $(notdir $(CONTAINERD_BUILD_TARGETS))
>  CONTAINERD_TAGS = no_aufs
>  
>  ifeq ($(BR2_PACKAGE_LIBAPPARMOR),y)
> diff --git a/package/delve/delve.mk b/package/delve/delve.mk
> index 408286e3b4..8206721fe2 100644
> --- a/package/delve/delve.mk
> +++ b/package/delve/delve.mk
> @@ -12,11 +12,9 @@ DELVE_DEPENDENCIES = host-pkgconf
>  
>  DELVE_TAGS = cgo
>  DELVE_BUILD_TARGETS = cmd/dlv
> -DELVE_INSTALL_BINS = $(notdir $(DELVE_BUILD_TARGETS))
>  
>  HOST_DELVE_TAGS = cgo
>  HOST_DELVE_BUILD_TARGETS = cmd/dlv
> -HOST_DELVE_INSTALL_BINS = $(notdir $(HOST_DELVE_BUILD_TARGETS))
>  
>  $(eval $(golang-package))
>  $(eval $(host-golang-package))
> diff --git a/package/distribution-registry/distribution-registry.mk b/package/distribution-registry/distribution-registry.mk
> index 901b9c40e5..a01a3c1710 100644
> --- a/package/distribution-registry/distribution-registry.mk
> +++ b/package/distribution-registry/distribution-registry.mk
> @@ -18,7 +18,6 @@ DISTRIBUTION_REGISTRY_BUILD_TARGETS = cmd/registry
>  # distribution-registry builds and installs the 'registry' executable, but
>  # that name is a bit too generic. Rename it to match the package name.
>  DISTRIBUTION_REGISTRY_BIN_NAME = distribution-registry
> -DISTRIBUTION_REGISTRY_INSTALL_BINS = distribution-registry
>  
>  # Inject the version as if done by upstream's wrapper Makefile
>  define DISTRIBUTION_REGISTRY_SET_VERSION
> diff --git a/package/docker-cli/docker-cli.mk b/package/docker-cli/docker-cli.mk
> index e118481838..7386b007cd 100644
> --- a/package/docker-cli/docker-cli.mk
> +++ b/package/docker-cli/docker-cli.mk
> @@ -38,6 +38,4 @@ define DOCKER_CLI_FIX_VENDORING
>  endef
>  DOCKER_CLI_POST_EXTRACT_HOOKS += DOCKER_CLI_FIX_VENDORING
>  
> -DOCKER_CLI_INSTALL_BINS = $(notdir $(DOCKER_CLI_BUILD_TARGETS))
> -
>  $(eval $(golang-package))
> diff --git a/package/docker-engine/docker-engine.mk b/package/docker-engine/docker-engine.mk
> index c39dc2b440..181975b26b 100644
> --- a/package/docker-engine/docker-engine.mk
> +++ b/package/docker-engine/docker-engine.mk
> @@ -70,8 +70,6 @@ define DOCKER_ENGINE_FIX_VENDORING
>  endef
>  DOCKER_ENGINE_POST_EXTRACT_HOOKS += DOCKER_ENGINE_FIX_VENDORING
>  
> -DOCKER_ENGINE_INSTALL_BINS = $(notdir $(DOCKER_ENGINE_BUILD_TARGETS))
> -
>  define DOCKER_ENGINE_INSTALL_INIT_SYSTEMD
>  	$(INSTALL) -D -m 0644 $(@D)/contrib/init/systemd/docker.service \
>  		$(TARGET_DIR)/usr/lib/systemd/system/docker.service
> diff --git a/package/mender-artifact/mender-artifact.mk b/package/mender-artifact/mender-artifact.mk
> index bcab91890a..7d6f0929e2 100644
> --- a/package/mender-artifact/mender-artifact.mk
> +++ b/package/mender-artifact/mender-artifact.mk
> @@ -115,7 +115,4 @@ HOST_MENDER_ARTIFACT_GO_ENV += \
>  
>  HOST_MENDER_ARTIFACT_LDFLAGS = -X github.com/mendersoftware/mender-artifact/cli.Version=$(HOST_MENDER_ARTIFACT_VERSION)
>  
> -HOST_MENDER_ARTIFACT_BIN_NAME = mender-artifact
> -HOST_MENDER_ARTIFACT_INSTALL_BINS = $(HOST_MENDER_ARTIFACT_BIN_NAME)
> -
>  $(eval $(host-golang-package))
> diff --git a/package/moby-buildkit/moby-buildkit.mk b/package/moby-buildkit/moby-buildkit.mk
> index 91560c1ed1..4ae1abde3a 100644
> --- a/package/moby-buildkit/moby-buildkit.mk
> +++ b/package/moby-buildkit/moby-buildkit.mk
> @@ -17,12 +17,8 @@ MOBY_BUILDKIT_BUILD_TARGETS = cmd/buildctl cmd/buildkitd
>  MOBY_BUILDKIT_LDFLAGS = \
>  	-X $(MOBY_BUILDKIT_GOMOD)/version.Version="$(MOBY_BUILDKIT_VERSION)"
>  
> -MOBY_BUILDKIT_INSTALL_BINS = $(notdir $(MOBY_BUILDKIT_BUILD_TARGETS))
> -
>  HOST_MOBY_BUILDKIT_TAGS = cgo
>  HOST_MOBY_BUILDKIT_BUILD_TARGETS = cmd/buildctl cmd/buildkitd
>  
> -HOST_MOBY_BUILDKIT_INSTALL_BINS = $(notdir $(HOST_MOBY_BUILDKIT_BUILD_TARGETS))
> -
>  $(eval $(golang-package))
>  $(eval $(host-golang-package))
> diff --git a/package/tailscale/tailscale.mk b/package/tailscale/tailscale.mk
> index 7019b9afc9..8f25b0cbd1 100644
> --- a/package/tailscale/tailscale.mk
> +++ b/package/tailscale/tailscale.mk
> @@ -10,7 +10,6 @@ TAILSCALE_LICENSE = BSD-3-Clause
>  TAILSCALE_LICENSE_FILES = LICENSE
>  TAILSCALE_GOMOD = tailscale.com
>  TAILSCALE_BUILD_TARGETS = cmd/tailscale cmd/tailscaled
> -TAILSCALE_INSTALL_BINS = tailscale tailscaled
>  TAILSCALE_LDFLAGS = \
>  	-X tailscale.com/version.longStamp=$(TAILSCALE_VERSION) \
>  	-X tailscale.com/version.shortStamp=$(TAILSCALE_VERSION)

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/4 v2] package/cni-plugin: simplify installation

[yann.morin]

From: "Yann E. MORIN" <yann.morin@orange.com>

In all theory, we could iterate over CNI_PLUGINS_INSTALL_BINS, which
already contains the basenames $(notdir) of the binaries to install,
but *_INSTALL_BINS is now an internal implementation detail, and
can't be guaranteed to be stable.

Hence, iterate over the list of targets, and somewhat duplicate the
install commands from the infra, using make's $(notdir) rather than
calling to the shell's to call basename.

Note: we need to stop setting _INSTALL_BINS, as a following commit will
check that it is not explicitly set, and fail otherwise.

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Christian Stewart <christian@aperture.us>
---
 package/cni-plugins/cni-plugins.mk | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/package/cni-plugins/cni-plugins.mk b/package/cni-plugins/cni-plugins.mk
index bccc1674aa..9a9ecf103b 100644
--- a/package/cni-plugins/cni-plugins.mk
+++ b/package/cni-plugins/cni-plugins.mk
@@ -27,7 +27,6 @@ CNI_PLUGINS_BUILD_TARGETS = \
 	plugins/meta/portmap \
 	plugins/meta/tuning \
 	plugins/meta/vrf
-CNI_PLUGINS_INSTALL_BINS = $(CNI_PLUGINS_BUILD_TARGETS)
 
 ifeq ($(BR2_PACKAGE_LIBAPPARMOR),y)
 CNI_PLUGINS_DEPENDENCIES += libapparmor
@@ -46,9 +45,9 @@ endif
 
 define CNI_PLUGINS_INSTALL_TARGET_CMDS
 	$(INSTALL) -d -m 0755 $(TARGET_DIR)/opt/cni/bin
-	$(foreach d,$(CNI_PLUGINS_INSTALL_BINS),\
-		$(INSTALL) -D -m 0755 $(@D)/bin/$$(basename $(d)) \
-			$(TARGET_DIR)/opt/cni/bin
+	$(foreach d,$(CNI_PLUGINS_BUILD_TARGETS),\
+		$(INSTALL) -D -m 0755 $(@D)/bin/$(notdir $(d)) \
+			$(TARGET_DIR)/opt/cni/bin/$(notdir $(d))
 	)
 endef
 
-- 
2.34.1

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/4 v2] package/cni-plugin: simplify installation

[Romain Naour via buildroot]

Hello Yann, All,

Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
> From: "Yann E. MORIN" <yann.morin@orange.com>
> 
> In all theory, we could iterate over CNI_PLUGINS_INSTALL_BINS, which
> already contains the basenames $(notdir) of the binaries to install,
> but *_INSTALL_BINS is now an internal implementation detail, and
> can't be guaranteed to be stable.
> 
> Hence, iterate over the list of targets, and somewhat duplicate the
> install commands from the infra, using make's $(notdir) rather than
> calling to the shell's to call basename.
> 
> Note: we need to stop setting _INSTALL_BINS, as a following commit will
> check that it is not explicitly set, and fail otherwise.
> 
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Christian Stewart <christian@aperture.us>

Reviewed-by: Romain Naour <romain.naour@smile.fr>

Best regards,
Romain


> ---
>  package/cni-plugins/cni-plugins.mk | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/package/cni-plugins/cni-plugins.mk b/package/cni-plugins/cni-plugins.mk
> index bccc1674aa..9a9ecf103b 100644
> --- a/package/cni-plugins/cni-plugins.mk
> +++ b/package/cni-plugins/cni-plugins.mk
> @@ -27,7 +27,6 @@ CNI_PLUGINS_BUILD_TARGETS = \
>  	plugins/meta/portmap \
>  	plugins/meta/tuning \
>  	plugins/meta/vrf
> -CNI_PLUGINS_INSTALL_BINS = $(CNI_PLUGINS_BUILD_TARGETS)
>  
>  ifeq ($(BR2_PACKAGE_LIBAPPARMOR),y)
>  CNI_PLUGINS_DEPENDENCIES += libapparmor
> @@ -46,9 +45,9 @@ endif
>  
>  define CNI_PLUGINS_INSTALL_TARGET_CMDS
>  	$(INSTALL) -d -m 0755 $(TARGET_DIR)/opt/cni/bin
> -	$(foreach d,$(CNI_PLUGINS_INSTALL_BINS),\
> -		$(INSTALL) -D -m 0755 $(@D)/bin/$$(basename $(d)) \
> -			$(TARGET_DIR)/opt/cni/bin
> +	$(foreach d,$(CNI_PLUGINS_BUILD_TARGETS),\
> +		$(INSTALL) -D -m 0755 $(@D)/bin/$(notdir $(d)) \
> +			$(TARGET_DIR)/opt/cni/bin/$(notdir $(d))
>  	)
>  endef
>  

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 4/4 v2] package/pkg-golang: catch use of legacy FOO_INSTALL_BINS

[yann.morin]

From: "Yann E. MORIN" <yann.morin@orange.com>

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Christian Stewart <christian@aperture.us>
---
 docs/manual/migrating.adoc | 5 +++++
 package/pkg-golang.mk      | 6 ++++++
 2 files changed, 11 insertions(+)

diff --git a/docs/manual/migrating.adoc b/docs/manual/migrating.adoc
index 4e6225a987..6ecc992502 100644
--- a/docs/manual/migrating.adoc
+++ b/docs/manual/migrating.adoc
@@ -222,3 +222,8 @@ from +-cargo2+ to +-cargo4+.
 In 2025.08, starting with systemd version 257, systemd-networkd requires kernel
 5.4 or later. If you are still using a kernel older than 5.4, please update
 your kernel or use an alternative network manager.
+
+[[migrating-golang-packages]]
+In 2025.08, the +FOO_INSTALL_BINS+ variable for golang packages is no longer
+supported; the list of binaries to install is automatically derived from
+the +FOO_BULD_TARGETS+ variable.
diff --git a/package/pkg-golang.mk b/package/pkg-golang.mk
index ff8d28aa7e..ffd50adecc 100644
--- a/package/pkg-golang.mk
+++ b/package/pkg-golang.mk
@@ -40,6 +40,12 @@ GO_BIN = $(HOST_DIR)/bin/go
 
 define inner-golang-package
 
+# Legacy
+ifneq ($$($(2)_INSTALL_BINS),)
+$$(error Package $(1) sets $(2)_INSTALL_BINS, which is no longer supported; \
+see the manual: https://buildroot.org/manual.html#migrating-golang-package )
+endif
+
 $(2)_BUILD_OPTS += \
 	-ldflags "$$($(2)_LDFLAGS)" \
 	-modcacherw \
-- 
2.34.1

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/4 v2] package/pkg-golang: catch use of legacy FOO_INSTALL_BINS

[Romain Naour via buildroot]

Hello Yann, All,

Le 01/07/2025 à 15:45, yann.morin@orange.com a écrit :
> From: "Yann E. MORIN" <yann.morin@orange.com>
> 
> Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
> Cc: Christian Stewart <christian@aperture.us>

Reviewed-by: Romain Naour <romain.naour@smile.fr>

Best regards,
Romain


> ---
>  docs/manual/migrating.adoc | 5 +++++
>  package/pkg-golang.mk      | 6 ++++++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/docs/manual/migrating.adoc b/docs/manual/migrating.adoc
> index 4e6225a987..6ecc992502 100644
> --- a/docs/manual/migrating.adoc
> +++ b/docs/manual/migrating.adoc
> @@ -222,3 +222,8 @@ from +-cargo2+ to +-cargo4+.
>  In 2025.08, starting with systemd version 257, systemd-networkd requires kernel
>  5.4 or later. If you are still using a kernel older than 5.4, please update
>  your kernel or use an alternative network manager.
> +
> +[[migrating-golang-packages]]
> +In 2025.08, the +FOO_INSTALL_BINS+ variable for golang packages is no longer
> +supported; the list of binaries to install is automatically derived from
> +the +FOO_BULD_TARGETS+ variable.
> diff --git a/package/pkg-golang.mk b/package/pkg-golang.mk
> index ff8d28aa7e..ffd50adecc 100644
> --- a/package/pkg-golang.mk
> +++ b/package/pkg-golang.mk
> @@ -40,6 +40,12 @@ GO_BIN = $(HOST_DIR)/bin/go
>  
>  define inner-golang-package
>  
> +# Legacy
> +ifneq ($$($(2)_INSTALL_BINS),)
> +$$(error Package $(1) sets $(2)_INSTALL_BINS, which is no longer supported; \
> +see the manual: https://buildroot.org/manual.html#migrating-golang-package )
> +endif
> +
>  $(2)_BUILD_OPTS += \
>  	-ldflags "$$($(2)_LDFLAGS)" \
>  	-modcacherw \

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot