Re: New pacakge containing binaries with same name as some from the packages cons, pscan and hsffig.
On Mon, 30 Apr 2007, Charles Plessy wrote:
* By shipping the binaries in /usr/lib/package, we give the final choice
to the user, who can add this on the top of his PATH in order to have a
direct access to the programs, without wrappers.
This would be my suggestion number 2.
* As we are dealing with packages with a low popularity. I think that
the proposed solution should work as usual when only one package is
installed.
I'm not convinced that this assumption is valid. In information science
we often solve 90% of the work in 10% of the time and the last 10% of
the work we need 90% of the time we deal with the exceptions. While
we have often packages with low popularity chances are good that inside
two low popularity packages binaries use the same name because they cover
a common field of tasks. Moreover there is nothing that will save us to
have a name space pollution with a basic (high frequently used package)
and one of our low popularity packages. See the issue with mummer:
I regard libgd-tools (containing /usr/bin/annotate) as very important
for several image processing tasks and chances are good that a dependency
of med-imaging will depend from it (if not currently than probably in
the future). Your assumption might lead to the fact that med-bio will
if not break med-imaging at least makes using med-imaging not as comfortable
as it normally could be.
* There should be a way in which when aptitude installing one of the
competing packages, the user can be sure that the /usr/bin commands
will point to his favorite program.
You'll never know users favourite program.
How about delegating this role to
Custom Debian Distributions ? For instance, EMBOSS is packaged for
Debian-Med. It would be great that when the med-common package is
installed, the /usr/bin programs would be the EMBOSS ones.
What you are proposing sounds a little bit like the alternatives system
with the exception that we here do not handle programs with alternative
functionality but just completely different programs - which will not
always be what users want.
All of this calls for having a common wrapper between a pair of packages
competing for the same binary name, but I do not know how to implement
this if we do not want to introduce a third package. Maybe we could ship
the same wrapper in each package, and divert it to avoid conflict
between the two copies ?
IMHO this would be a weak technique to implement something that might
confuse users. While I think that my suggestion 2. (/usr/lib usage) is
the best from a distributors point of view it might be that my first
prposal ist the best from a CDD point of view. If a CDD is important
enough that upstream authors know it and really *want* their package
introduced, they will regard our hint that they should use names that
do not conflict with other tools.
I personally think that we are just dealing with a documentation issue
and need to give users a leading hand how to deal with name space pollution.
They will have to do it anyway if they intall it locally without a
Debian package so it is no real harm if we do not try to implement a
technical system that might introduce other kind of trouble.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: