Re: dummy packages and "Replaces:" field
On Thu, 23 Jun 2005 08:32:35 -0500, Steve Greenland
<steveg@moregruel.net> said:
> I think that there have been proposals for a new header that
> accomplishes what you want, but it's never gone anywhere. I suspect
> that the effort has not been viewed as worthwhile, given that
> there's no new functionality. Dummy packages work, and have the
> advantage that it's very clear what is going on.
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
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
--
Some rise by sin and some by virtue fall.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: