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
