On Fri, 5 Jan 2007, Joey Hess wrote: > Santiago Vila wrote: > > Well, what I see is that after an upgrade from sarge to etch, the user > > may have an empty /usr/doc. But even in such case, it is not base-files > > business to remove symlinks indiscriminately in /usr/doc, as they > > could be there because the system admin puts them there deliberately > > for whatever reason. > > How would you feel about removing only broken symlinks? > > if [ -d /usr/doc ] && [ ! -L /usr/doc ]; then > find -L /usr/doc -maxdepth 1 -mindepth 1 -lname \* -print0 | xargs -0 > rm -f > rmdir --ignore-fail-on-non-empty /usr/doc 2>/dev/null > fi
That would be still be dangerous, and it would also be trying to fix bugs in other packages. What if the system admin has a symlink in /usr/doc which points to a removable volume which may or may not be mounted? We just remove it anyway, without any questions? There may be symlinks in /usr/doc mainly for two reasons: Because the user created them, or because some package forgot to remove them. The problem is that there is no simple way to know which is the case, and I hope we agree that we don't want to implement a complex solution for something which is not such a big problem. If the user created the symlink, it should be respected as much as anything in /usr/local, for example. If some package forgot to remove it, the buggy package should be fixed. If base-files had to care about packages not removing symlinks properly, that would be like hiding a problem instead of actually fixing it, and "Debian does not hide problems". To summarize: Each package should care about their own symlinks, as we agreed to do a lot of time ago. [ The directory /usr/doc itself is different, as you have clearly shown ]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
