* Simon McVittie <s...@debian.org> [240422 05:02]: > On Mon, 22 Apr 2024 at 09:44:12 +0200, Simon Josefsson wrote: > > Philip Hands <p...@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
