On Sat, Jul 31, 1999 at 10:32:51PM -0700, Joey Hess wrote: > Modify dpkg-buildpackage to handle FHS move (#41729) > * Proposed by Julian Gilbey. > * Another /usr/share/doc transition proposal. This one is to make > dpkg-buildpackage move /usr/doc to /usr/share/doc when a package > is built.
You know, I think this is a really bad idea. I am not going to formally object however because at the moment it is an idea and it's not the worst idea out there to be sure. However it does lead me to ask if it might not be more reasonable just to fix the problem with dpkg and moving /usr/doc. The problems with moving /usr/doc file by file to /usr/share/doc are not the same as would be involved with /var/lib to /var/state---moving /var subdirs around can actually cause problems since each package would have to do the moving in a preinst script (many places to break) because there's no other way for a package to make sure the files it requires for safe operation are not unavailable for the time spent moving. So that change was was undone in the 2.1 draft of the FHS. All right, first of all if a script or program were written to move files one at a time, preserving permissions, and handled moving of links using readlink (a sh/perl hack because readlink is not in a base package, a number of packages now have to use it including X and Netscape..) to make sure that the symlinks get made properly and all, it would be possible to safely move /usr/doc to /usr/share/doc. No other technical issues stand in the way if whatever does the moving does it right. However, there are two issues we cannot easily account for (actually we could but I insist that we do not): 1. Local partition setup. It's possible to write checks to figure out where /usr/doc really is, what partition it's part of, etc and the same vor /usr/share/doc... And we could try to figure out how best to handle the move this way and if there's enough space and whatnot. This will get hairy, we shouldn't do it even if it's possible. Too many variables. 2. Disk space. My suggestion is that the destination of /usr/share/doc should have 125% of the space /usr/doc uses already free. If this is not the case, the move cannot happen automatically and the user must intervene manually. Arguably if we check for /usr/doc and /usr/share being on the same partition we could skip the check and all that, but still, it's better to let the user do this, yaknow? Because of this before any attempt is made to change anything, a quick size check should be made and tell the user about it, then give them the option to not do the move or run $SHELL to have a look around and fix things. The script would move files one at a time. I realize this will take a long while and on many systems would not even be necessary (on my system at the moment mv share/doc share/docsav; mv doc share/doc; ln -s share/doc doc; mv share/docsav/* share/doc would probably be sufficient to fully handle things. Still, the slow way is more likely to always work and you know that the estimated size check is more than big enough to handle the move safely. Of course this all depends on dpkg. As I understand it, before if package foo installs /usr/doc/foo and you move /usr/doc to /usr/share and replace doc with a symlink as is probably the FHS preferred way of doing this I guess, dpkg will have issues when the package is built with /usr/share/doc instead of /usr/doc. It will PROBABLY handle unpacking the new version okay, but it will probably then delete everything from /usr/doc/foo that no longer is supposed to exist which would remove the newly installed /usr/share/doc files. Obviously, the best solution to this is to make dpkg follow symlinks in places where it matters like when dpkg is about to remove files that should now go away and stuff like that. I realize realpath is hideously expensive but dpkg doesn't currently use a huge amount of CPU (it wastes all its time thrashing through the database...) Still if the docs are never going to be avalable in one place and not the other, dpkg MUST be involved, or we resort to one symlink per package as we used to and these symlinks must be maintained by postinst and prerm to keep dpkg's grubby hands off them. The other option is to make the doc tools handle looking in both places and just stick a release note someplace that docs at the moment need to be espected to be found in either /usr/share/doc or /usr/doc. If people know to expect it they will deal with it, believe me. And they won't freak over it either. A few people will have issues to contend with (not enough space to have /usr/doc in two different places at once) but this too is easily fixed---just move /usr/doc by hand to a single subdir of /usr/share/doc and create that symlink instead. dpkg will deal with that no problem. Otherwise I don't see that we have options here. There is no technical reason we can't just forget the transition. The tools can be modified to look for docs in both places and (I guess?) already have been in some cases. If apache's missing /doc annoys you, just use dwww or something which CAN build a composite of /usr/doc and /usr/share/doc. All arguments aside, we're running out of options (especially since there are a dozen proposals and everyone seems to be formally objecting to every proposal that isn't theirs ...) -- Joseph Carter <[EMAIL PROTECTED]> Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -------------------------------------------------------------------------- Since when has the purpose of debian been to appease the interests of the mass of unskilled consumers? -- Steve Shorter
pgp6eWMkMAQh5.pgp
Description: PGP signature
