Bug#322762: no blocking bugs anymore
Joey Hess wrote: I note that we still arn't 100% sure we've caught every last upgrade issue involving /usr/doc, since AFAIK puiparts has not been used to test upgrades of everything. Pity :( Also, I see that there are still some lintian warnings about it at http://lintian.debian.org/reports/Tpostinst-should-not-set-usr-doc-link.html but I guess these are obsolete, since it was last updated in August. I spot-checked a couple of packages and they seem fixed. More up2date findings: http://merkel.debian.org/~ballombe/lintian-etch-i386/reports/Tpostinst-should-not-set-usr-doc-link.html Still obsolete packages, though. Yes, I think it's time to reassign it to base-files, to get the directory removed on upgrade if it's empty. Yay! -- ยท''`. If I can't dance to it, it's not my revolution : :' :-- Emma Goldman `. `' Proudly running Debian GNU/Linux (unstable) `- www.amayita.com www.malapecora.com www.chicasduras.com
Bug#322762: no blocking bugs anymore
Hi, Set any bugs about /usr/doc stuff to being blockers of this bug report. Use this as a tracking/coordination bug for the remainder of the transition. Note that once this transition is complete we will need to do something in base-files to remove the /usr/doc directory, if it is empty. It won't be empty in all cases, for example a user might have non-debian or old packages that have not transitioned still installed. This bug can be reassigned to base-files to deal with that last step once it is no longer blocked by any other bugs. Well, today I have fixed the last two remaining bugs that blocked this bug (I'll have to followup to them to see whether the fixes will get to Etch, but that is not really on topic for this bug per se). Hence, I think now is the time to continue with the next steps as outlined in the first message in the bug, right? Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322762: no blocking bugs anymore
Thijs Kinkhorst wrote: Well, today I have fixed the last two remaining bugs that blocked this bug (I'll have to followup to them to see whether the fixes will get to Etch, but that is not really on topic for this bug per se). Excellent. I note that we still arn't 100% sure we've caught every last upgrade issue involving /usr/doc, since AFAIK puiparts has not been used to test upgrades of everything. Also, I see that there are still some lintian warnings about it at http://lintian.debian.org/reports/Tpostinst-should-not-set-usr-doc-link.html but I guess these are obsolete, since it was last updated in August. I spot-checked a couple of packages and they seem fixed. Hence, I think now is the time to continue with the next steps as outlined in the first message in the bug, right? Yes, I think it's time to reassign it to base-files, to get the directory removed on upgrade if it's empty. -- see shy jo signature.asc Description: Digital signature
Bug#322762: no blocking bugs anymore
On Fri, 5 Jan 2007, Thijs Kinkhorst wrote: Hi, Set any bugs about /usr/doc stuff to being blockers of this bug report. Use this as a tracking/coordination bug for the remainder of the transition. Note that once this transition is complete we will need to do something in base-files to remove the /usr/doc directory, if it is empty. It won't be empty in all cases, for example a user might have non-debian or old packages that have not transitioned still installed. This bug can be reassigned to base-files to deal with that last step once it is no longer blocked by any other bugs. Well, today I have fixed the last two remaining bugs that blocked this bug (I'll have to followup to them to see whether the fixes will get to Etch, but that is not really on topic for this bug per se). Hence, I think now is the time to continue with the next steps as outlined in the first message in the bug, right? No, the next step is to close the bug and celebrate it. If the system has only official Debian packages installed, and you upgrade all of them in a way that none of them put files under /usr/doc anymore, then dpkg should automatically remove /usr/doc when upgrading the last /usr/doc-using package, and there is really no need to do anything else. base-files is not, and should not be, a fix-everything package. Once we have fixed all our packages, we are already compliant, and that's all what we should reasonably do. The local admin is still free to put files in /usr/doc if he wishes, but it's not our job to fiddle with those files, move them around, or anything similar. Our job was fixing our packages, and that's now done. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322762: no blocking bugs anymore
On Fri, 5 Jan 2007, Joey Hess wrote: Yes, I think it's time to reassign it to base-files, to get the directory removed on upgrade if it's empty. Please don't. Dpkg already does that. See my previous message. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322762: no blocking bugs anymore
Santiago Vila wrote: Please don't. Dpkg already does that. See my previous message. It doesn't seem to in all cases, I have empty /usr/doc directories on some systems. -- see shy jo signature.asc Description: Digital signature
Bug#322762: no blocking bugs anymore
On Fri, 5 Jan 2007, Joey Hess wrote: Santiago Vila wrote: Please don't. Dpkg already does that. See my previous message. It doesn't seem to in all cases, I have empty /usr/doc directories on some systems. Then it's dpkg fault, in which case you should reassign it to dpkg. The purpose of base-files is not to fix bugs in other packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322762: no blocking bugs anymore
What's going on is that a base sarge system looks like this: kodama:/usr/doc# ls -l total 0 lrwxrwxrwx 1 root root 15 Jan 5 22:41 at - ../share/doc/at lrwxrwxrwx 1 root root 17 Jan 5 22:41 cpio - ../share/doc/cpio lrwxrwxrwx 1 root root 21 Jan 5 22:41 ipchains - ../share/doc/ipchains lrwxrwxrwx 1 root root 18 Jan 5 22:41 klogd - ../share/doc/klogd lrwxrwxrwx 1 root root 25 Jan 5 22:41 liblockfile1 - ../share/doc/liblockfile1 lrwxrwxrwx 1 root root 21 Jan 5 22:41 sysklogd - ../share/doc/sysklogd kodama:/usr/doc# dpkg -S /usr/doc base-files: /usr/doc When this is upgraded to etch, base-files is upgraded before most of these symlink containing packages. So dpkg cannot remove the /usr/doc directory despite that being the last package to own it. The symlinks are eventually removed, but the directory remains. (Reading database ... 7749 files and directories currently installed.) Preparing to replace base-files 3.1.2 (using .../archives/base-files_4_i386.deb) ... Unpacking replacement base-files ... dpkg: warning - unable to delete old file `/usr/doc': Directory not empty Setting up base-files (4) ... BTW, there are also crufty old systems where /usr/doc contains a mess of broken symlinks due to broken old packages that were removed before being fixed, or possibly due to upgrade bugs in existing packages that we've missed: Sesse joeyh: heh. I actually have tons of stuff left in /usr/doc; most of it from 1998, though. :-) Sesse six symlinks, though. probably left over in some upgrade... Sesse joeyh: well... tftpd-hpa, raidtools2, python, freefont, fai, dhcp, at Sesse all but python and freefont are simply gone The following in base-files's postinst would fix both issues. if [ -d /usr/doc ] [ ! -L /usr/doc ]; then find /usr/doc -maxdepth 1 -mindepth 1 -type l -print0 | xargs -0 rm -f rmdir --ignore-fail-on-non-empty /usr/doc 2/dev/null fi -- see shy jo signature.asc Description: Digital signature
Bug#322762: no blocking bugs anymore
On Fri, 5 Jan 2007, Joey Hess wrote: What's going on is that a base sarge system looks like this: [ snipped datailed explanation ] Ok, I see. Not dpkg fault. If it helps I can reintroduce /usr/doc in base-files in etch ;-) The following in base-files's postinst would fix both issues. if [ -d /usr/doc ] [ ! -L /usr/doc ]; then find /usr/doc -maxdepth 1 -mindepth 1 -type l -print0 | xargs -0 rm -f rmdir --ignore-fail-on-non-empty /usr/doc 2/dev/null fi 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. BTW: Are we talking about the base-files version in etch, for upgrades from sarge, or the one in lenny for upgrades from etch? (or both) I could add the rmdir thing for etch, if the release managers think we need it. If not, we can leave this to the user. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322762: no blocking bugs anymore
Santiago Vila wrote: Ok, I see. Not dpkg fault. If it helps I can reintroduce /usr/doc in base-files in etch ;-) I'd prefer the rmdir in the postinst, and not doing it only on upgrade, but unconditionally, and leaving it in for a few releases. That way, whenever a system finally gets the last /usr/doc symlinks cleaned out, it will have /usr/doc removed by a base-files upgrade .. eventually. It's still not uncommon for upgraded systems to have /usr/doc symlinks. For example, they might have an obsolete sarge package like ipchains installed. 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. I consider this highly unlikely, to the extent that I'm sure I can find hundreds of other situations where we make some assumption about the system that could break if the admin did something similarly unusial. BTW: Are we talking about the base-files version in etch, for upgrades from sarge, or the one in lenny for upgrades from etch? (or both) I could add the rmdir thing for etch, if the release managers think we need it. If not, we can leave this to the user. This isn't an RC issue, so I doubt the release managers want to be bothered about it. While I'd prefer to see it fixed for etch, if necessary I can wait one release more. -- see shy jo signature.asc Description: Digital signature
Bug#322762: no blocking bugs anymore
On Fri, 05 Jan 2007, Joey Hess wrote: The following in base-files's postinst would fix both issues. if [ -d /usr/doc ] [ ! -L /usr/doc ]; then find /usr/doc -maxdepth 1 -mindepth 1 -type l -print0 | xargs -0 rm -f rmdir --ignore-fail-on-non-empty /usr/doc 2/dev/null fi Wouldn't just running if [ -d /usr/doc ] [ ! -L /usr/doc ]; then rmdir --ignore-fail-on-non-empty /usr/doc; fi in the postinst resolve this issue without having the issues of removing symlinks that the system administrator placed there on purpose? Granted, if the upgrade was split and basefile's postinst ran before the other packages, the final cleanup would take another upgrade to go into effect... but it would avoid mucking with files that don't belong to basefiles. Don Armstrong -- There are two types of people in this world, good and bad. The good sleep better, but the bad seem to enjoy the waking hours much more. -- Woody Allen http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322762: no blocking bugs anymore
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 -- see shy jo signature.asc Description: Digital signature
Bug#322762: no blocking bugs anymore
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]
Bug#322762: no blocking bugs anymore
Santiago Vila wrote: 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. It's impossible to fix a buggy package that is no longer in debian, or that is no longer installed. -- see shy jo signature.asc Description: Digital signature
Bug#322762: no blocking bugs anymore
On Fri, 5 Jan 2007, Joey Hess wrote: Santiago Vila wrote: 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. It's impossible to fix a buggy package that is no longer in debian, or that is no longer installed. Very true, but for the same reason we should not try to fix something which does not make so much harm if there is a risk of breaking something else. There will always be packages which leave cruft in the system when installed and then purged, not just symlinks for the doc transition, but that's not a good reason for base-files to take care of the cruft they create. There is a package called cruft which searches for missing and unexplained files. I think that would be a much better place for the functionality you have in mind, as anything which is still in /usr/doc after the /usr/doc transition is certainly unexplained, or at least misplaced. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
