Please add GNU id-utils to Fedora
jim at meyering.net
Mon May 14 08:11:33 UTC 2012
Miloslav Trmač wrote:
> On Fri, May 11, 2012 at 10:14 AM, Jim Meyering <jim at meyering.net> wrote:
>> Miloslav Trmač wrote:
>>> On Thu, May 10, 2012 at 9:49 PM, Greg McGary <greg.mcgary at gmail.com> wrote:
>>>> Minor conflict: the name of one of id-utils main commands "lid" is also the
>>>> same as an existing command, though installed in a different place. id-utils
>>>> has /usr/bin/lid, while libuser has /usr/sbin/lid.
>>> Yeah, that's come up before. There's no great solution I'm afraid,
>>> one or the other will have to change
>> Technically there is no need to change a name.
>> In Debian, one can have two lid programs installed, one in /usr/bin
>> and the other in /usr/sbin[*], so why not in Fedora?
> Apart from being confusing, it effectively overrides libuser's use of lid.
>> Sure, a different solution would be better, but renaming a command like
>> idutils' lid (in use by some for >15 years) does not seem reasonable.
>> Any opinions on whether this issue is big enough to NAK
>> a review request or addition of the package to Fedora?
> I'm pretty sure that naming conflicts in /usr/bin have happened before
> in Fedora, I'm not sure how they were resolved.
Even in a relatively minimal system, I see many programs installed
in both /sbin and /bin, though none seem to conflict:
$ comm -12 <(cd /sbin;env ls -1) <(cd /bin;env ls -1)
Odd that some point from /bin to /sbin, and others from /sbin to /bin.
Some use relative symlinks, others use absolute.
Compare the output of these commands:
cd /sbin; ls -og $(comm -12 <(cd /bin;env ls -1) <(cd /sbin;env ls -1))
cd /bin; ls -og $(comm -12 <(cd /bin;env ls -1) <(cd /sbin;env ls -1))
> Anyway, we can't please both sets of users at the same time. If the
> above-mentioned reference to previous naming conflicts in Fedora does
> not result in a generally-acceptable solution, what about the
> lid is renamed in both packages to lid-libuser and lid-idutils (or
> something), respectively. Both packages ship an alias script
> somewhere in /etc. A new package is created, providing a /usr/bin/lid
> script, that instructs the user to add the alias to their ~/.bashrc,
> and fails.
If cohabitation is not acceptable, that is a fine compromise that
would let us move forward. However, it should suggest more than an
alias/function addition, because those are not desirable/useful for
non-command-line use e.g., via other scripts that invoke lid. Instead,
suggesting to install a lid wrapper via one of these commands:
printf '#!/bin/sh\nexec lid-idutils "$@"\n' > $f && chmod a+x $f
printf '#!/bin/sh\nexec lid-libuser "$@"\n' > $f && chmod a+x $f
[ or use f=/usr/local/bin/lid for a system-wide choice. ]
I would also request that users who encounter the failing "lid" script
write to e.g., bug-idutils at gnu.org to inform us of their choice (either way),
so that eventually, if we get stats to support a move and everyone agrees
it's ok, we could phase out the always-failing lid script.
>  The script could also automatically run one of the lid's, if there
> were only one installed - but then merely installing a new package
> could break user's workflow, which I think is undesirable.
More information about the devel