Control: forcemerge 182747 -1 Hi!
On Tue, 2015-02-24 at 00:44:02 +0100, Michael Prokop wrote: > Package: dpkg > Version: 1.17.23 > Severity: grave > I've reproduced this behaviour on Debian/jessie with dpkg 1.17.23, > but the original issue appeared on Debian/wheezy with dpkg 1.16.15 > (and old-stable as well as unstable might be very probably affected > as well). > > What happened (with anonymized data): a Debian package shipped a > file called /srv/repository/release/myscript.sh. Its underlying > directory /srv/repository on the file system of the host is a > *symlink* pointing to a different directory (because the data is > served via NFS from a different system). When the package gets > removed/purged (or in a package update the file > /srv/repository/release/myscript.sh is no longer provided) the > symlink /srv/repository gets removed by dpkg, even though there are > other files inside the directory. > > The original data behind the symlink isn't removed/touched/modified, > so no data loss from that perspective. *But* by removing the symlink > - even though there's still data inside the directory behind the > symlink - this can cause serious service disruptions (and also > conflicting data sets), as it happened at a customer of mine a few > hours ago. [BTW, for the investigation it would have been nice if > there would be some information about such removals in dpkg's > logs, it was far from trivial to identify this behaviour.] Yes, I'm afraid that's currently "expected" behavior. dpkg expects to manage all paths it touches in the filesystem. In this case you are placing files inside an already existing (and externally managed) hierarchy, but dpkg does not know that, and when no other package owns that path it tries to remove it. Fixing this requires to track file meta-data, because otherwise dpkg does not know if there's been any local changes, or whether a path is really a symlink or a directory. A workaround could be to avoid removing a path if it contains other paths inside the same package, but that has too many corner cases. Consider the following, a package A ships /dir and /dir/file, and /dir is a symlink on the filesystem. And suddenly package B Replaces A and takes over /dir/file. If package B gets removed, then package A only owns /dir, and when that gets removed dpkg cannot know if it needs to remove it or not, because it does not contain any owned paths. So this is for now either a packaging or admin problem, and a wishlist from dpkg PoV. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
