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

Re: /usr/share/doc vs. /usr/doc transition, debate reopened



On Tue, 17 Aug 1999, Ian Jackson wrote:

> I'm not sure yet what the test cases people are presenting are.  dpkg
> is not supposed ever to remove a nonempty directory and replace it
> with a symlink to a different directory.  If someone can reproduce it
> doing this I'd be very interested.

One (the?) specific problem is if a single package is the only owner of a
directory, say /dev - and that same package converts that directory to
something else - dpkg will happily erase that directory and everything in
it. 

This might be considered a misguided feature, it should check to ensure
that the dir is 'empty' (no files owned by the package in question inside
it) before replacing it. 

Just a few weeks ago someone uploaded a botched makedev which caused dpkg
to do exactly this - I have the original .deb in my home dir on master if
you'd like to try it out ;>

A secondary problem with the /usr/doc symlink example is more ingrained
into the way things work.. Consider package A,

 Version 1 has
   /usr/doc/A/foo
 Version 2 has 
   /usr/share/doc/A/foo

Someone installs Version 1, and then places a symlink to/from
/usr/share/doc/A then goes to install Version 2. Something along the
following occur:

1)  dpkg unpacks /usr/share/doc/A/foo and backs up it up foo.dpkg.old - it
    does not touch the /usr/share/doc/A link
2)  dpkg removes foo.dpkg.old
3)  dpkg removes /usr/doc/A/foo because it is a file from the old package
4)  dpkg removes the (now empty) directory/link /usr/doc/A

Of course since /usr/doc/A/foo and /usr/share/doc/A/foo are the same file
you end up with an empty directory at step 4..

Jason


Reply to: