* Simon McVittie <
smcv@debian.org> [240422 05:02]:
On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote:
Philip Hands <phil@hands.com> writes:
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)