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

Purging configurations of non-installed transitional packages


Since I hate having tons of configuration files lying around from my various 
tests (and build-dep installing orgies), I do "dpkg -l | grep ^rc | cut -f 
3 -d \  | xargs dpkg -P" every now and then.  Actually, I first look at the 
list, and this proved very important here...

What happened: Somehow, I seem to have transitioned from sarge ssh to 
openssh-client/-server directly without first installing the 'ssh' 
transitional package because I installed some package which depended on 
openssh-client directly.  With the above operation, I then tried to purge 
the old ssh package - which, obviously, blew my ssh configuration along 
with the 'sshd' user.  In this case, I was prepared because I had an idea 
that this could happen - but nonetheless, I think it shouldn't.

How to prevent this?  (btw: ntp has the same problem: /var/lib/ntp was 
removed without me noticing.  Obviously this is not near as bad, as it 
won't even stop ntp working)

Huge hack #1: openssh-server (new package) knows the contents of the old 
ssh.preinst/ssh.postinst, so it could remove those file on installation or 
replace them by newer ones that take into account the transition.  
Obviously this is dangerous and should probably be secured by md5 of the 
known files.

Huge hack #2: openssh-server/openssh-client know that they're replacing the 
old package.  So they could just remove records of ssh from the database of 
installed packages by surgery.  I feel that this one could even be made 
official if specified properly as a method to transition package names  
(and replacing surgery by official sourcery by dpkg).  OTOH there's bound 
to be many pitfalls, and probably no two transitions are ever the same.

Other methods?  The only sane way I can think of is a hard dependency on the 
transitional package for a full release cycle.  But that means keeping 
useless packages around for a long time :-(

Yes, it all only was a problem because I was mixing stable and testing, but 
I think being able to do that is one of the biggest assets Debian GNU/Linux 
has over other distributions, so making this as easy as possible is A Good 
Thing(tm) in my book.

-- vbi

featured link: http://fortytwo.ch/gpg/subkeys

Attachment: pgpea2C9Vai6j.pgp
Description: PGP signature

Reply to: