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

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

        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).

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: