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

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.

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

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: