Re: Packages replaced by different packages (was: Re: glibc)
On 1 May 1997, Kai Henningsen wrote:
> Here's an idea. We could make a new version of A, that contains no files,
> that depends on X, and whose *inst/*rm scripts can do whatever package-
> specific cleanup is needed (like, for example, moving around config
> files). The version could be something like 99:0.obsoleted-1.
> Would dpkg notice that the package actually had no files left, or
> otherwise, would it be doable to make it notice this, so it can clean up
> after the package, like when another package replaces all the files of
> this package?
With this method we would be accumulating packages for compatibility...
we could create a section `obsolete' for these packages. Other solution
I've proposed (but it would need to be implemented in dpkg =/) is to add
a header `Implied-by:' to the new package. This way the packaging
front-end can handle this smarter, just by selecting the new package.
Exmaple:
Package: fetchmail
Implied-By: popmail
When package inctionality is splitted among several packages, this scheme
also aplies:
Package: tool-docs
Implied-By: tool (<= 1.0.4-3)
This would fix a `i installed the new version and {all the docs,some
functionality} are/is gone' problem...
--
Nicolás Lichtmaier.-
nick@feedback.com.ar
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: