Binary conflict between Midnight Commander and MinIO Client

[Mathias Gibbens]

Currently, Midnight Commander is packaged for Debian as `mc`. I am
looking at packaging the MinIO Client (needed for a future release of
Incus), which also unfortunately names its binary `mc`. MinIO upstream
has been pretty clear that they don't consider this a bug[1].

While that might work for them, it obviously doesn't at a higher
packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
for any comments or suggestions on my plan for packaging the MinIO
Client. Following what several other distributions have done[2], I'm
planning to name the source/binary packages "minio-client" and the
binary provided from that package will be `mcli`.

Thanks,
Mathias

[1] -- https://github.com/minio/mc/blob/master/CONFLICT.md
[2] -- https://repology.org/project/minio-client/versions

[Marco d'Itri]

Post by Mathias Gibbens
While that might work for them, it obviously doesn't at a higher
packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
for any comments or suggestions on my plan for packaging the MinIO
Client. Following what several other distributions have done[2], I'm
planning to name the source/binary packages "minio-client" and the
binary provided from that package will be `mcli`.

Go for it, I think that there is no good solution for this case.
Everybody who cares then will manually create a mc -> mcli symlink.

[Simon Josefsson]

Post by Marco d'Itri

Post by Mathias Gibbens
While that might work for them, it obviously doesn't at a higher
packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
for any comments or suggestions on my plan for packaging the MinIO
Client. Following what several other distributions have done[2], I'm
planning to name the source/binary packages "minio-client" and the
binary provided from that package will be `mcli`.

+1

Post by Marco d'Itri
Go for it, I think that there is no good solution for this case.
Everybody who cares then will manually create a mc -> mcli symlink.

Several Homebrew packages uses an approach that I regard as superior to
what the debian ecosystem provides for this problem: putting files in a
path that users can add to their $PATH to get upstreams' desired binary
name, when there is a conflict with a historically established name. So
for this example, minio-client could create a symlink like this

/usr/libexec/minio-client/bin/mc -> /usr/bin/mcli

and users who really want the upstream behaviour can solve this by
modifying environment variables.

/Simon

[Mathias Gibbens]

Post by Simon Josefsson

Post by Marco d'Itri

  While that might work for them, it obviously doesn't at a higher
packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
for any comments or suggestions on my plan for packaging the MinIO
Client. Following what several other distributions have done[2], I'm
planning to name the source/binary packages "minio-client" and the
binary provided from that package will be `mcli`.

+1

Post by Marco d'Itri
Go for it, I think that there is no good solution for this case.
Everybody who cares then will manually create a mc -> mcli symlink.

Several Homebrew packages uses an approach that I regard as superior to
what the debian ecosystem provides for this problem: putting files in a
path that users can add to their $PATH to get upstreams' desired binary
name, when there is a conflict with a historically established name.  So
for this example, minio-client could create a symlink like this
/usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
and users who really want the upstream behaviour can solve this by
modifying environment variables.

I like that idea, thanks! It would be easy enough to add that to
Incus' $PATH while making it simple for an end user to modify their
local environment to directly use `mc` if they wish.

Mathias

[Philip Hands]

...

Post by Simon Josefsson
/usr/libexec/minio-client/bin/mc -> /usr/bin/mcli

Might I suggest that the link goes the other way, so that the symlink
lives in /usr/bin? That way the existence of the lib directory is
somewhat self-documenting.

If you're looking for examples, it seems that fd-find and binutils-avr
do something like this (although they seem to be linking into ../lib/
presumably for historical reasons).

Cheers, Phil.

[Simon Josefsson]

Post by Philip Hands
...

Post by Simon Josefsson
/usr/libexec/minio-client/bin/mc -> /usr/bin/mcli

Might I suggest that the link goes the other way, so that the symlink
lives in /usr/bin? That way the existence of the lib directory is
somewhat self-documenting.
If you're looking for examples, it seems that fd-find and binutils-avr
do something like this (although they seem to be linking into ../lib/
presumably for historical reasons).

It seems this approach could use some documentation, if we want to have
some consistent implementation of this idea in Debian. While I usually
dislike symlinks in /usr/bin/ I think there is some advantages. I'm
also not sure where a good path component to store such binaries are,
libexec or lib? Or share?

/Simon

[Simon McVittie]

Post by Philip Hands
Might I suggest that the link goes the other way, so that the symlink
lives in /usr/bin? That way the existence of the lib directory is
somewhat self-documenting.

Having the real executable in /usr/lib(exec) and the symlink in /usr/bin
also makes it possible to be somewhat consistent with packages that don't
normally add themselves to the PATH at all, but could be added to the PATH
by a system integrator, sysadmin or user on specialized systems.

For example flatpak-xdg-utils contains reimplementations of
xdg-email and xdg-open which are probably too limited for use on
ordinary desktop systems, but very suitable for use inside Flatpak,
Toolbx or similar containers. At the moment it installs them into
/usr/libexec/flatpak-xdg-utils/, with nothing in /usr/bin. The
Debian-derived Steam Runtime container environment installs
flatpak-xdg-utils, and also creates non-dpkg-managed symlinks in /usr/bin
pointing to those executables.

(On a normal read/write dpkg system it would not be desirable to create
non-dpkg-managed symlinks in /usr/bin, but in a "write-once" container
image it seems acceptable.)

Adding symlinks like
/usr/bin/flatpak-xdg-open -> ../libexec/flatpak-xdg-utils/xdg-open
seems like a reasonable thing to do, and I might do that in a future version
of flatpak-xdg-utils.

I'm also not sure where a good path component to store such binaries are,
libexec or lib? Or share?

To me, this technique seems most in line with how the FHS and GNU Coding
Standards define /usr/libexec.

/usr/share could be used for scripts, but not for native executables,
so we need to choose a location for native executables that are handled
like this (like the ones in flatpak-xdg-utils) in any case; and having
chosen that location, we might as well use that same location for scripts
(in the same way that /usr/bin holds both native executables and scripts)
rather than needing to invent a second path just for scripts.

Older packages use /usr/lib as a substitute for /usr/libexec because the
FHS (and therefore Debian) didn't document /usr/libexec until relatively
recently.

smcv

[Marvin Renich]

Post by Simon McVittie

Post by Philip Hands
Might I suggest that the link goes the other way, so that the symlink
lives in /usr/bin? That way the existence of the lib directory is
somewhat self-documenting.

Having the real executable in /usr/lib(exec) and the symlink in /usr/bin
also makes it possible to be somewhat consistent with packages that don't
normally add themselves to the PATH at all, but could be added to the PATH
by a system integrator, sysadmin or user on specialized systems.

I don't think either way is best for all situations, but I think that
having the mc symlink in a directory other than /usr/bin (or /usr/sbin)
is the only way that is compatible with Debian's policies.

If a package puts the symlink in /usr/bin (e.g. having an additional
package minio-client-compat), that package must declare a Conflicts: mc,
and while this is still technically against policy (IIUC), there is
already precedent for this method (or at least there has been in the
past).

If the sysadmin puts the symlink there, it goes against FHS and then the
sysadmin is responsible for ensuring that mc is never installed.

On the other hand, if a symlink named mc is placed in
/usr/lib/minio-client, with the binary named minio-client in /usr/bin,
there is no policy violation, the choice of which binary is invoked by
mc at the command line is entirely up to individual users (either
through modifying $PATH or placing a symlink in ~/bin or ~/.local/bin/),
and both packages are co-installable. If the sysadmin desires, a
symlink can be placed in /usr/local/bin.

In fact, I think /usr/lib/minio-client/mc -> /usr/bin/minio-client is
completely unnecessary. Whatever is done must be documented (at least
in /usr/share/doc/minio-client/README.Debian, and possibly also in the
man page). It is just as easy to document placing a symlink in ~/bin or
~/.local/bin as it is to document modifying $PATH in ~/.profile.

I think this should become the standard way to deal with this situation:
the package should not create any compatibility symlink, and the
documentation should describe that individual users can place a symlink
in ~/bin or ~/.local/bin or that the sysadmin can place a symlink in
/usr/local/bin, giving a non-standard default for all users.

A script in /usr/share/doc/minio-client/examples/ can help the user get
this correct, checking for the existence of ~/bin and ~/.local/bin and
setting up the symlink.

<rant>
I believe upstream's reluctance to change the executable name is grossly
self-centered. The current use of mc has a long history and is still
very popular. I think the FLOSS community should do everything they can
to discourage this type of behavior, and any upstream behaving this way
should be called out loudly as being anti-social. A lot of time gets
wasted every time this situation comes up.
</rant>

...Marvin

[Andreas Tille]

Hi,

Post by Philip Hands

Post by Simon Josefsson
/usr/libexec/minio-client/bin/mc -> /usr/bin/mcli

Might I suggest that the link goes the other way, so that the symlink
lives in /usr/bin? That way the existence of the lib directory is
somewhat self-documenting.

That's an interesting hint. In Debian Med we are using a common
directories

/usr/lib/debian-med/bin/
/usr/lib/debian-med/man/

where those binaries will be moved to and have some kind of a
README.Debian template[1]. Changing this to have the real executable /
manpage to /usr/lib/debian-med/* makes sense.

We simply advise Debian Med users to set PATH to that dir and have
all the name-clashed binaries inside Debian Med without additional
interaction.

Kind regards
Andreas.

[1] https://salsa.debian.org/med-team/ea-utils/-/blob/master/debian/README.Debian?ref_type=heads

[Jeremy Bícha]

Post by Andreas Tille

Post by Philip Hands

Post by Simon Josefsson
/usr/libexec/minio-client/bin/mc -> /usr/bin/mcli

Might I suggest that the link goes the other way, so that the symlink
lives in /usr/bin? That way the existence of the lib directory is
somewhat self-documenting.

That's an interesting hint. In Debian Med we are using a common
directories
/usr/lib/debian-med/bin/
/usr/lib/debian-med/man/
where those binaries will be moved to and have some kind of a
README.Debian template[1]. Changing this to have the real executable /
manpage to /usr/lib/debian-med/* makes sense.

I believe moving those binaries to a subdirectory of /usr/libexec/
would better comply with FHS 3.0. Maybe this could be done for the
Trixie release?

I guess a subdirectory of /usr/share/ would be appropriate for the
extra manpages.

Thank you,
Jeremy Bícha

[Helmut Grohne]

Post by Mathias Gibbens
I like that idea, thanks! It would be easy enough to add that to
Incus' $PATH while making it simple for an end user to modify their
local environment to directly use `mc` if they wish.

Let me express a concern regarding this route. If we modify $PATH (in
packages or as an end user), that may subtly break other packages
expecting a particular behavior. Let me sketch a few examples.

1. A user adds the minio path to their default shell. When the,
mc.desktop launcher may now launch the minio thing instead of mc.

2. If Incus' $PATH is augmented, any tools run from Incus will also be
affected by that change and may end up with an incompatible binary.

I don't think the approach of augmenting the $PATH is a silver bullet
here. Rather, it defers the problems to the end user where none of
Debian's QA may have any effect. Stuff looks as if it were working, but
the composed $PATH produces subtle breakage that is hard to diagnose.

In the functional package manager world, this is less of a problem,
because there executables tend to be hard coded using their full path.
In principle, Debian could do the same, but then we loose the ability to
add our own custom wrappers around existing tools to our $PATH.

There is no silver bullet.

Helmut

[Mathias Gibbens]

Post by Helmut Grohne

   I like that idea, thanks! It would be easy enough to add that to
Incus' $PATH while making it simple for an end user to modify their
local environment to directly use `mc` if they wish.

Let me express a concern regarding this route. If we modify $PATH (in
packages or as an end user), that may subtly break other packages
expecting a particular behavior. Let me sketch a few examples.

Ultimately I ended up packaging the MinIO client binary as
`/usr/bin/minio-client` and wrote a brief readme for the package
describing the naming conflict with mc. Then on the Incus side I simply
adjusted the binary name it looks for when searching for the MinIO
client.

Mathias

[Jonathan Dowland]

Post by Marco d'Itri
Go for it, I think that there is no good solution for this case.
Everybody who cares then will manually create a mc -> mcli symlink.

Indeed, they will: so I would suggest that the chosen binary name for
minio-client should *not* be mcli, which doesn't appear to clash with
anything in Debian already, but almost certainly clashes with something
outside Debian (which might be packaged in the future), and has no
currency upstream. I'd go with "minio-client" as the binary name, which
also aligns with the binary package name (which as an end-user I always
appreciate), is more discoverable, and very unlikely to clash with
anything else. Then set up a /usr/libexec/mc as suggested else-thread,
and end-users will either use that or set up their own shell alias.