Re: Please add GNU id-utils to Fedora |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Miloslav Trmač wrote:
> On Fri, May 11, 2012 at 10:14 AM, Jim Meyering <jim@xxxxxxxxxxxx> wrote:
>> Miloslav Trmač wrote:
>>> On Thu, May 10, 2012 at 9:49 PM, Greg McGary <greg.mcgary@xxxxxxxxx> 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)
authconfig
authconfig-gtk
authconfig-tui
dracut
eject
halt
hddtemp
makemap
mock
ping6
poweroff
preupgrade
preupgrade-cli
rdistd
reboot
setup
system-config-authentication
system-config-keyboard
system-config-network
system-config-network-cmd
tmpwatch
tracepath
tracepath6
udevadm
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:
f=~/bin/lid
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@xxxxxxx 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.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
[Fedora Announce]
[Fedora Kernel]
[Fedora Testing]
[Fedora Legacy Announce]
[Home]
[Fedora Tools]
[Fedora PHP Devel]
[Kernel List]
[Fedora Legacy]
[Fedora Maintainers]
[Fedora Maintainers]
[Fedora Desktop]
[PAM]
[Red Hat Development]
[Big List of Linux Books]
[Gimp]
[Yosemite News]