Re: Binaries with the same name
On la, 2008-02-09 at 19:48 +0100, David Paleino wrote:
> The problem is that "translate" by <anibal> does only de<->en translations,
> while "my" translate offers a wider range of options and conversions (and it's
> expandable, through a XML configuration file). Thus I don't believe that using
> the alternatives system (which, I admit, I cannot use, since I never needed it
> for my packages) would be a suitable solution. This is way I suggested him to
> rename his binary to something less generic than "translate".
In general, the problem with renaming in these kinds of situations is
that the older package has users and some of those users are used to the
old name of the binary in the old package. If it's just a matter of
training users, it's not a huge deal, but there might be programmatic
uses, which would have to be tracked down. Thus, it is generally
speaking better to let the old package keep the binary name and pick a
new name for the binary in the new package.
This is an example of why it's best to avoid introducing generic names
into the name space: in a distribution as large as Debian, sooner or
later there will be a clash. Thus, in an ideal world, neither of these
two packages would contain a binary called translate.
In the real world, in my opinion, we stick to "first come, first
served", meaning that you, David, should rename the binary in your
package. This is suboptimal, but as far as I can see, the best
situation.
(We should also stick to shaking a finger at anibal, for introducing a
generic name. And at me for being verbose and for putting entire
paragraphs in parentheses. (It's an afflication I got from implementing
my own Lisp. (Although, actually, I did it even beforehand. (So perhaps
it's really that I implemented my own Lisp to be able to use parentheses
without making an ass of myself.))))
Alternatives are an option if both commands do the same thing, and have
more or less the same command line interface. Is that the situation
here?
Conflicts would be the wrong solution, as you pointed in a later mail.
Since the only reason for the conflict is the clash in binary names,
preventing users to have the two packages installed at the same time is
unnecessary.
Reply to: