Web lists-archives.com

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

Paride Legovini writes ("Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]"):
> It would certainly work, but as you say it is still irritating. I like
> the idea of putting the binaries in a different directory *and*
> providing a "name compatibility package", as it has been already
> suggested. This package would provide the symlinks in /usr/bin and set
> the needed Conflicts. In this way we allow both packages to be installed
> at the same time while leaving the users enough freedom to chose what to
> have in their PATH.

This is not a bad idea but we should impose some serious restrictions:

 * The basic principle is that the compat name, and the compat
   package, is provided for users and nothing in Debian (even the
   package itself) may use it.

 * Other packages MUST NOT depend on or recommend the -debcompat
   package.  The reasons for this should be obvious.

 * No program (including parts of the same package) should run the
   program by the compat name (by setting PATH, for exmaple).

   This is because PATH settings leak: modern software often calls
   other programs, and even if it doesn't do so now it may do so in

> As we want the packages to be discoverable, I would name them something
> like this:
> <package>-debcompat (for "compatible with the other Debian packages"):
> installs binaries in /usr/share/<package>/bin, does not set Conflicts,
> warns the user in the Description, Suggests <package>.
> <package>: installs the /usr/bin symlinks, sets the required Conflicts,
> depends on <package>-compat.

I think this is backwards.  Also it will result in violations of the
rules I state above.

> A "first come best served, modulo a different debian-devel consensus,
> modulo CTTE" policy could be good enough to decide which package
> deserves to install the "real" binary in /usr/bin.

I am in favour of my "cut the child in half" rule, as a general rule.

> We have to recognize that there is no perfect solution here. If we
> enforce the rename it will often be a big hassle for several people for
> a little gain while still leaving room for ambiguity (e.g. user set-up
> aliases and symlinks). On the other side if we allow Conflicts to be
> always used we will end up having useful but incompatible packages. I
> think the best compromise is somewhere in between.

Convenience for the amjority needs to be tempered with justice, and
consideration for the future.


Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.