Please add GNU id-utils to Fedora

Jim Meyering jim at
Mon May 14 08:11:33 UTC 2012

Miloslav Trmač wrote:
> On Fri, May 11, 2012 at 10:14 AM, Jim Meyering <jim at> wrote:
>> Miloslav Trmač wrote:
>>> On Thu, May 10, 2012 at 9:49 PM, Greg McGary <greg.mcgary at> 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.
> Right.
>> 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
> following?

> 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.[1]
>     Mirek

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 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.

> [1] 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 mailing list