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

Re: When to use update-alteratives



On Thu, Aug 11, 2005 at 01:11:10AM -0700, Russ Allbery wrote:
> Sebastian Kuzminsky <seb@highlab.com> writes in a debian-devel thread:

> > Now, after bumbling around the Debian developer docs a little more, I
> > found this.  Section 3.10 of the Policy Manual states:

> >     <http://www.debian.org/doc/debian-policy/ch-binary.html#s-maintscripts>

> >     All packages which supply an instance of a common command name (or, in
> >     general, filename) should generally use update-alternatives, so that
> >     they may be installed together. If update-alternatives is not used,
> >     then each package must use Conflicts to ensure that other packages
> >     are de-installed.

> > Seems like a match to me.  git.deb and cogito.deb both supply an
> > instance of a common command name (/usr/bin/git).  So shouldn't I use
> > update-alternatives?

> > The only other mention I found of update-alternatives was in Appendix
> > F of the Policy Manual, here:

> >     <http://www.debian.org/doc/debian-policy/ap-pkg-alternatives.html>

> > Appendix F is marked as being "from old Packaging Manual".  The wording
> > here suggests that in order to use update-alternatives, the alternatives
> > need to "do the same thing" (like nvi and vim, for example).  This seems
> > to be in mild conflict with section 3.10: 3.10 talks about filename
> > conflicts without mentioning "interfaces" (which I take to mean the
> > "purpose" of the program or file).

> I believe that the statement that alternatives are supposed to be used for
> commands that do roughly the same thing should be normative, and I'd
> rather not see normative requirements in an appendix (plus, the appendices
> aren't necessarily normative, as noted in Section 1.1).

> Therefore, I think it would be good to add a statement like:

>     update-alternatives must only be used to manage multiple
>     implementations of a common command that all do roughly the same
>     thing, and must not be used if the conflicting commands do completely
>     different things.

> That may be too verbose.  There's some fuzziness in "roughly" and
> "completely" that probably can't be pinned down more than that.

10.1. Binaries
--------------

     Two different packages must not install programs with different
     functionality but with the same filenames.  (The case of two programs
     having the same functionality but different implementations is handled
     via "alternatives" or the "Conflicts" mechanism.  See Section 3.10,

So, it already *is* in a normative part of the document, it's just not
necessarily presented in the best order for readers to consume it. :/

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                  to set it on, and I will move the world.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature


Reply to: