[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New pacakge containing binaries with same name as some from the packages cons, pscan and hsffig.

Le Sat, Apr 28, 2007 at 03:47:28PM +0200, Andreas Tille a écrit :
> 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.

Dear all,

I agree with Andreas that that kind of situation is likely to happen
more and more: I understand that people who use frequently a pacakge
want short names. But let us look at the bright side of the problem:
binary conflicts happen more often in Debian because we have more
packages, so it pushes us ahead and gives us an opportunity to innovate

In the following proposal, I try to combine the best of each points
proposed by Andreas with some idea of mine to involve CDDs in the

* 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.

* 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

* 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. 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.

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 ?

Have a nice day,

Charles Plessy
Wako, Saitama, Japan

Reply to: