Re: FHS - transition
Biased summary:
My scheme:
* keep the user's filesystem consistently laid out during transition.
* allows the transition to be controlled explicitly by a single script.
* allows us to start moving packages to /usr/share nearly straight
away.
* can preserve backward compatibility indefinitely
(ie old packages on new systems)
* will require upgrade of only one core package (which does not
itself have many dependencies) for forward compatibility (new
packages on old systems)
My opponents' scheme:
* uses dpkg to do bulk moving, which is not what it was designed for.
* needs a flag day at which point old packages stop working.
* will require upgrade of many packages for forward compatibility.
* put lots of packages onto each others' critical paths for changing
to /usr/share.
* will create a mess (existence of both /usr/share/info and
/usr/info, etc.) which will eventually have to be cleaned up with
scripts anyway.
Santiago Vila writes ("Re: FHS - transition"):
...
> Better having to upgrade the manpage program than upgrading base-files,
> which has nothing to do with manpages.
In some sense, perhaps. However: base-files is one (critical)
package. Someone expecting to use new versions of things might well
expect to have to upgrade it, much as they might upgrade libc or
ld.so.
Contrast changing the browser programs: it's not just man that needs
to be changed. Any program that has a search path that should include
/usr/share and used to include /usr needs to be changed. This
includes all flavours of Emacs (for /usr/info only, since the lisp
directories are now in /usr/share already), any other manpage
browsers, dwww and similar tools, nroff (tmac.*), etc. etc. etc.
Expecting a user to have to upgrade their Emacs so that info files
from the new package can be read is not reasonable.
Furthermore, if we make any other similar global changes base-files is
a good place to put them. It means that you can get the requirements
for all your half dozen early-upgraded packages satisfied easily
without having to upgrade half the system.
I think the only other way to get the required ease of partial upgrade
is to _refuse_ to allow _any_ new-layout packages to be released until
at least one or two full releases after _all_ browser packages have
been changed. (And how do we check that we didn't miss one?)
With my proposal we can start making the move straight away.
...
> Well, it depends on what we understand by "works fine". For me, it would
> be very very ugly indeed to have things in the old place forever.
So what's your objection to doing the copying ?
I think perhaps you just want to push the problem out of some
installation script (eg base-files's postinst in my scenario) into
dpkg. The files will actually have to move eventually, it's just a
question of whether dpkg does it one package at a time, or a
well-controlled special-purpose script does it all at once per system.
I don't think dpkg is the right tool for this.
dpkg's directory handling has been specially arranged to work well
with symlinks to directories, for transition schemes like the one I
proposed.
Surely the scheme I proposed, with a transitional symlink, and then
moving everything at some future date, is just what a sysadmin would
do if they were maintaining the system by hand ?
> It is not enough that we find the docs in /usr/share/doc in a Debian
> system to be FHS compliant. It is necessary that every package is FHS
> compliant, so that they may be installed also in another FHS system,
> without problems. We can not rely on strange symlinks being there
> forever. I don't think it would be true if we say that our system
> is FHS but our individual packages are not.
Huh? After base-files is changed to include the symlink, packages can
straight away be changed individually to use /usr/share.
Ian.
Reply to: