[Debichem-devel] [Debichem-commits] [debichem] r4720 - unstable/elkcode/debian

[Michael Banck]

Hi,

On Sun, Sep 22, 2013 at 12:17:07PM +0200, Daniel Leidert wrote:
> Am Samstag, den 21.09.2013, 22:53 +0200 schrieb Michael Banck:
> > Hi,
> > 
> > On Tue, Aug 27, 2013 at 08:49:43PM +0000, dleidert at alioth.debian.org wrote:
> > > * debian/rules (override_dh_install): Rename binary to elk-lapw (closes: #720044).
> > 
> > I think it would be better to keep the binary as "elk" and conflict with
> > the "elk" package.  The other elk package does not appear to be very
> > popular either and I cannot image a lot of users would like to install
> > both.
> 
> IMO the rename is a good decision. The project itself states, that
> someone using and customizing the elk code package should use a name
> like elk-foo [1]. 

I think they rather mean an academic fork, adding or changing
functionality in a major way.  Also, I read that more as a project
naming, not necessarily the binary name naming.

> Maybe we can agree to some other name, that follows this rule, if you
> don't like elk-lapw? 

If we change the name away from elk, I think elk-lpaw is a good name.

> The probably best way might be talking to the project and explaining
> the issue.

I talked to them initially about the naming collision of the
source/binary package, and they said they wouldn't mind any name at all
(I proposed elkcode and elk-lpaw back then).

> ATM IMO we can still do all these things easily, because popcon
> currently doesn't list any installation.
 
Heh, sure :)

> > Is there some other disadvantages I am missing for a Conflicts?
> 
> Well, that is usually a violation of its dedicated use. 

AIUI, Conflicts is exactly for packages which have a name-collision in
one of their files, where the alternatives system is not applicable
(which is only supposed to be used for several variants of the same
binary/interface, like vi and vim).


Michael