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. :-)
...Marvin
----- Forwarded message from Manoj Srivastava <[EMAIL PROTECTED]> -----
From: Manoj Srivastava <[EMAIL PROTECTED]>
Date: Thu, 23 Jun 2005 11:25:03 -0500
Subject: Re: dummy packages and "Replaces:" field
Message-ID: <[EMAIL PROTECTED]>
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
dependencies.
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
has.
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).
manoj
----- End forwarded message -----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
