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

Bug#315583: explanation of Conflicts/Replaces/Provides

Package: www.debian.org
Severity: wishlist

The following explanation from Manoj Srivastava about when to use
Conflicts/Replaces/Provides versus a dummy package is the best I have
seen.  It would make an excellent addition to Chapter 7 of the Debian
Policy Manual.

I hope this is the right pseudo-package; I couldn't find a
pseudo-package for "official Debian documents"; perhaps a wishlist bug
against bugs.debian.org requesting a new pseudo-package is in order.  :-)


----- Forwarded message from Manoj Srivastava <srivasta@debian.org> -----

From: Manoj Srivastava <srivasta@debian.org>
Date: Thu, 23 Jun 2005 11:25:03 -0500
Subject: Re: dummy packages and "Replaces:" field
Message-ID: <87r7etxcps.fsf@glaurung.internal.golden-gryphon.com>

        OK. Heres trhe thing. Suppose there is a package foo, now not
 being developed. There is a package baz that depends on it. There is
 a new package foo, that in some sense provides a replacement. Let us
               ^^^ bar
 consider a couple of scenarios:

  a) bar is a drop in replacement -- it uses the same config, for
     example, it hs the same functionality, and is better than foo,
     has support, security fixes, what have you -- and in all cases
     should be installed on any machine on which foo was
     installed. This is currently done using "dummy" packages, and it
     allows for depending packages a window of time to upgrade

        With a dummy package foo; baz can continue to depend on foo
     during the transition, while the user is actually using bar, the
     transition is not stalled. Even if baz has a versioned dependency
     on foo. This window for transition is critical.

  b) bar is _not_ a drop in replacement -- perhaps it has different
     config files, subtly different behaviour, and you do not want the
     system to automatically replace foo without a human decision to
     do so. (say, kinda like the MTA's in debvian, that all conflict,
     replace, and provide the virtual mail-transport-agent package).

        In this case, one does _not_ use a dummy package, one uses
     conflict, replace, and provide (and perhaps a NEWS.Debian in a
     new version of foo), and works with dependent packages to depend
     on foo | bar, if at all possible (which it may not be, given bar
     is not a drop in replacement for foo). It would be better if bar
     could have a versioned provides, but hey, one works with what one

        In no way should support for option (b) be dropped, you
 certainly should not change the semantics of option (b) to work the
 same as option (a). And any replacement for option (a) should
 continue to provide the window for the transition (a flag day
 changeover usually does not work).


----- End forwarded message -----

Reply to: