[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: policy summary for past two weeks

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

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

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 <knghtbrd@debian.org>             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

Attachment: pgp4cq2f993vr.pgp
Description: PGP signature

Reply to: