Re: New pacakge containing binaries with same name as some from the packages cons, pscan and hsffig.
On Sat, 28 Apr 2007, Charles Plessy wrote:
We have uploaded a package to experimental, "emboss", and it contains
binaries whose name are already "taken" by your packages: cons, pscan
and splitter.
I think we will face the situation of name space pollution more and
more in the future. A good thing would be if we could educate projects
to use specific prefixes (for example em_* for the emboss binaries).
But I'm not to optimistic that this will be accepted by upstream developers.
I recently had the same problem when packaging mummer where I renamed
/usr/bin/annotate to usr/bin/mummer_annotate. This is not a really
good solution but "annotate" is such a generic name that it is not
a good idea to use such names at all.
http://packages.qa.debian.org/e/emboss.html
Emboss is a suite of many command line programs, it has web interfaces
and people use the program names in scripts. I am therefore quite
reluctant to rename the Emboss binaries, as I think that people will
just not use the package if I do this.
You are right this is really troublesome. Another solution the
previous maintainer of phylip found (and I adopted this solution)
to put all binaries of the package into /usr/lib/<pkgname> and
use a wrapper that calls the binaries there. (Have a look into
the phylip package if my sense is not really clear.) For the own
script of the users we could teach them to prepend their PATH with
PATH="/usr/lib/emboss;$PATH"
which should let all user scripts work fine.
I would like to have your opinion on what to do. The most
straightforward would be to swich the priorities of our packages to
extra and conflict on each other, but I do not know how to interpret the
policy... it this solution acceptable ?
Well, I do not know the other packages and thus I do not really know
whether it is really acceptable. There are a lot of choices - just
pick a reasonable one:
1. Ask upstream to use em_* names - or rename all binaries according
to this (probably not reasonable because users own scripts will
fail.
2. Use the wrapper method like PhyLip packae does.
3. Consult popularity contest results for the packages that cause
the name space polution and ask the maintainers / upstream
authors whether they see a chance for a rename.
4. If popularity contest result fr the other packages is low
your suggested conflicts solution might be acceptable
5. Use diversions and just divert the other packages names. This
might be a little bit dangerous if you find no reasonable way
to inform users about the fact that the other programs might be
renamed and you have to make sure that the other packages will
not break terrribly.
I think suggestions 1. to 4. are quite similar acceptable and 5. is
kind of an ugly one. I don't know much enough about all these projects
to decide, which solution is the best one.
Thanks for caring for EMBOSS
Andreas.
--
http://fam-tille.de
Reply to: