Il giorno Sun, 10 Feb 2008 12:16:17 +0200
Lars Wirzenius <liw@iki.fi> ha scritto:
> 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.
In fact, the Ubuntu package renames it to "translate-bin". But that's awkward
to me: what's the difference between "translate" and "translate-bin"? One
should have to read both manpages to understand. But if we have, for example,
"translate-de-en" and "translate", the differences are clear. However, I don't
believe I'll ever use translate-bin.
Looking at the package information of translate, it already depends on a
"trans-de-en", which is clearer to me. (trans-de-en is the dictionary,
translate is the tool using it)
> 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.
Agreed on that; educating upstream is sometimes difficult though (i.e. I
haven't contacted upstream yet -- I'd like to see if the thing is solvable
inside Debian)
> 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.
As already stated, I'll do that only if really necessary / if the clash is
unsolvable. Please read further in the next paragraph.
> ...
>
> 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?
I think not.
(from libtranslate-bin)
$ translate -h
Synopsis:
translate {-? | -v | --list-services}
translate [-s SERVICES] [-f LANG] [-t LANG] -l
translate [-s SERVICES] [-f LANG] [-t LANG] {HTTP_URL | HTTPS_URL}
translate [-s SERVICES] [-f LANG] [-t LANG] [--max-threads=N]
[--max-retries=N] [FILE]
...
-l, --list-pairs List the available language pairs
$ translate -l | wc -l
948
$
(from translate)
$ translate -h
...
USAGE:
translate [-niwvh] [-l languages] [words to translate]
...
$
where currently -l look for files in /usr/share/trans/. And there's just a
package providing files in the whole Debian distribution: trans-de-en:
$ apt-file search /usr/share/trans/
trans-de-en: usr/share/trans/de-en
$
I believe I can claim the use of the generic name "translate".
Using alternatives would be the best solution to me, since they provide
"more-or-less" the same functionality. Yet, translate covers only de-en, while
libtranslate-bin covers more pairs.
(and the main difference is that translate uses a local dictionary, while
libtranslate-bin needs an Internet connection to lookup translations)
> 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.
True.
I won't post an RFS before solving this situation.
Kindly,
David
--
. ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|---- http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Attachment:
signature.asc
Description: PGP signature