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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
