[Debichem-devel] [Debichem-commits] [debichem] r4720 - unstable/elkcode/debian
Michael Banck
mbanck at debian.org
Sun Sep 22 10:45:53 UTC 2013
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
More information about the Debichem-devel
mailing list