Re: Renaming lsh?
Hello,
Edward Betts <edward@debian.org> writes:
> Hello, I am a Debian developer. As you may or may not know work is being
> carried out to include your program, lsh, in Debian GNU/Linux. Unfortunately
> we have come across a problem, there is already a package in Debian called
> lsh. You might have heard of the program, it is designed to operate like an
> MS-DOS command problem. As we see it there are a number of ways of fixing
> this problem, all envolve one of the programs changing its name:
I'm aware of the conflict.
> a) the current dos-like-shell, lsh is renamed, and we call the name for the new
> free-secure-shell-clone, lsh.
>
> b) the new free-secure-shell-clone is renamed, and the current dos-like-shell,
> lsh keeps the same name.
>
> c) the new free-secure-shell-clone is renamed, but only in Debian, the current
> dos-like-shell lsh keeps the same name.
>
> The first option is not good, anybody using the lsh package will find that
> once they have upgraded to a new version of Debian the lsh package is
> completely different. If they are using lsh as a log in shell, they will no
> longer be able to log in. The current free-secure-shell-clone, lsh has been in
> Debian for 3 years, it has a well established name.
I think this description misses the problem by quite some distance.
It's not the name of the *package* that creates problems for you (I
have suggested using the name "lsh-utils" or some such for the
package, which as far as I know should solve this aspect of the
conflict in a reasonable way). The problem is the *filename* of one of
the installed program, "lsh". Note that lsh-the-free-ssh includes
several programs: A client, a server and a handful other utilities.
If I'm allowed to give a short rant, I think it is really bad that
debian appearantly has no mechanism to let the *user* resolve name
conflicts between installed packages. It's really not a new problem,
there are lots of conflicts between system supplied make
programs and gnu make, conflicts between GNU ld and system ld,
conflicts between programs in /usr/bin and /usr/ucb/bin, just to take
a few examples that I have stumbled upon. And beyond these
incompatibilities, it is quite common to have to keep several slightly
incompatible versions of the same program installed, where some users
prefer the latest version but others depend on behaviour only found in
some older version.
Ok, these examples are somewhat different than the lsh case, as the
conflicting programs tries to solve the same problems, but despite
this I think the problems caused by these conflicts are similar, as
they appear to users. Accidentally getting /usr/ucb/bin into your
PATH, or using emacs-20.3 instead of emacs-19.34, causes real lossage.
Another example that is more similar to the lsh case is the case of
"rsh". On a random un*x system, rsh is most likely to be the remote
shell program (originally from BSD, I think). But it could also be a
"restricted shell", being used as a login shell for some users on some
systems.
So what have people been doing in the past to resolve name conflicts?
They have been using prefixes (gmake, gld) in order not to collide
with different programs with similar names. And they are using tools
like modules (for a decent modules implementation, have a look at
ceder's cmod program). In general, I think it is best to have name
conflicts resolved per user, *not* for the entire system, which is why
I don't think I quite like debian's update-alternatives mechanism
(yes, I understand that update-alternatives is probably not applicable
in the lsh case).
If you want to eradicate any real-world name conflict that might
appear before the innocent eyes of a debian user, I don't think that
is realistic, and perhaps not even desirable. And I'm afraid you won't
find me as helpful as you would like. A better approach is to make
sure that the debian system can handle packages that uses the same
name for different things, delegating details of the name space
configuration to each user (this is part tech, part policy, I guess).
And in the mean time, do the minor tweaks needed to make applications
into debian packages.
> The second option IMHO is the best. The new lsh is not very well know, it is
> not too late to change it's name. There would then be no problems with the
> Debian packages.
I'm not completely unwilling to consider a name change. But I don't
like it, and I won't do it lightly. The particular name that have been
discussed is "psst". But how do I know that a new name won't collide
with some other program that I have never heard about, in somebody
else's software distribution?
> The third options could possibly considered a fork, it is very-sub optimal,
> but works around all our current problems, and avoids problems assosiated with
> option a. Possible problems that might arise from this change are that people
> installing Debian and looking for lsh, the free-secure-shell-clone, would be
> confused by the lsh package being a dos-command-shell.
What you can do, which I think would solve the problem, is to hack
configure.in in lsh-the-ssh2-implementation. Add a ./configure-time
option to install the lsh binary under a different name, and have the
debian scripts enable that option. I would have no problem with
including such an option, and it involves a lot less pain, research
and considerations than a name change. For the latter problem, the
user would probably just add an lsh alias to his or her personal
startup files.
An even easier partial solution is to simply mark the "lsh" (dos-like
shell) as conflicting with "lsh-utils" (ssh-like stuff). But IIRC that
was rejected because conflicting meanings of the name "/usr/bin/lsh"
was against debian policy.
Regards,
/Niels
Reply to: