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

Packages replaced by different packages (was: Re: glibc)

david@sw.ods.com (David Engel)  wrote on 30.04.97 in <19970430203019.42265@sw.ods.com>:

> There are two problems with having totally new packages.  First, users
> have to be educated that the old packages have been replaced with new
> ones.  Second, in the case of timezone/timezones, the /etc/timezone
> conffile has to be moved from one package to another.  When I first
> upgraded my system, dpkg didn't notice the conffile had moved and then
> proceeded to delete it when I purged the old package.

This is, of course, a general problem, which hs been discussed before:  
what to do if package A is replaced by package X (and both could actually  
be sets of packages)? The problem right now is that this is known only to  
some people, not to any software.

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?

And what would be needed in the X control file?

MfG Kai

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: