Re: FHS - transition
Ian Jackson wrote:
>Biased summary:
>
>My scheme:
> * keep the user's filesystem consistently laid out during transition.
For what value of "consistent"? If the search path for man pages includes
both /usr/man and /usr/share/man, why should it be inconsistent to have
man pages in both? We already have man pages in multiple locations.
> * allows the transition to be controlled explicitly by a single script.
I don't think the transition needs to be "controlled" by anything. We
can make it work right on its own.
> * allows us to start moving packages to /usr/share nearly straight
> away.
True.
> * can preserve backward compatibility indefinitely
> (ie old packages on new systems)
We can do that anyway. I don't think anyone has tried to say that we'll
ever have to remove /usr/info from the search paths for info files,
or /usr/man from search paths for man pages.
Joel Klecker wrote:
>The current search path is:
>
>"/usr/info:/usr/local/info:/usr/info:/usr/local/lib/info:/usr/lib/info
>:/usr/local/gnu/info:/usr/local/gnu/lib/info:/usr/gnu/info:/usr/gnu/li
>b/info:/opt/gnu/info:/usr/share/info:/usr/share/lib/info:/usr/local/sh
>are/info:/usr/local/share/lib/info:/usr/gnu/lib/emacs/info:/usr/local/
>gnu/lib/emacs/info:/usr/local/lib/emacs/info:/usr/local/emacs/info:."
That seems to have quite a lot of backwards- and sideways-compatibility
stuff already. Leaving /usr/info in there indefinitely doesn't look
like much of a problem to me.
> * will require upgrade of only one core package (which does not
> itself have many dependencies) for forward compatibility (new
> packages on old systems)
True.
>My opponents' scheme:
> * uses dpkg to do bulk moving, which is not what it was designed for.
It doesn't (as I understand it) make dpkg move anything at all. In fact,
it doesn't, strictly, involve moving anything. All that happens is
that dpkg installs new versions of files, and removes old versions.
The new versions merely happen to be in a different place.
> * needs a flag day at which point old packages stop working.
Why? Old FSSTND-compatible locations can be kept in paths indefinitely
with no work.
> * will require upgrade of many packages for forward compatibility.
How many browsers are in use on each machine? How many machines are
upgraded one package at a time? (I suspect most are upgraded lock, stock
and barrel to a complete new release; I think we've told our users in the
past that this is the way to be sure everything will work at its best).
> * put lots of packages onto each others' critical paths for changing
> to /usr/share.
(Posessive of "other" has no apostrophe, BTW.)
I don't think this involves as many packages as you seem to think.
> * 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.
Why is it a mess to have files in two places? Why does this matter?
I don't think there will be any need to use scripts to clean up; when
all packages use /usr/share/{man,info}, /usr/{man,info} should be empty.
When base-files no longer includes them, dpkg will remove them.
>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.
They might expect to have to upgrade man/info browsers in order to have
them use FHS-compliant search paths. If they don't want to upgrade,
we can tell them how to edit the appropriate configuration files, or set
the appropriate environment variables. (Or upgrade dpkg and base-files,
if using the scheme below.)
>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.
But few users use all of the huge variety of browsers that we have
available. They may only have to upgrade man-db and info (or edit their
config) to see man pages and info files from the new locations.
>Expecting a user to have to upgrade their Emacs so that info files
>from the new package can be read is not reasonable.
I can't believe that it isn't possible -- or easy -- to tell an existing
emacs to look for info files in /usr/share/info. I really can't.
>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?)
We already have a bug tracking system, and we fix bugs on a regular basis.
If a browser doesn't look in the right place, it's a bug. We start the
FHS transition at the start of a development cycle, and report bugs until
all of the browsers look in the right places. If the user has a buggy
browser, he can upgrade it, surely? And all the commonest browsers will
have been debugged in plenty of time.
>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 doesn't move files (except for renaming within the same directory).
It installs and it removes. That's what it's -good- at. I've been quite
happy with the way dpkg enables things to be placed in different places
in different versions of a package, and how it keeps track of the files
and cleans up the old version of the package properly. Why is this
situation different?
>dpkg's directory handling has been specially arranged to work well
>with symlinks to directories, for transition schemes like the one I
>proposed.
And this has never struck me as being a particularly good feature.
Certainly, it's a Good Thing that dpkg follows symlinks inserted by the
system administrator, but I think having our distribution deliberately
put a symlink in dpkg's way is a Bad Thing. The reason being, as soon
as dpkg follows a symlink, its database no longer accurately reflects
the reality of the system.
If the sysadmin comes along and removes, say, the /usr/share/info symlink
which pointed at /usr/info, knowing that their info browser can handle
both locations, and replaces the symlink with a directory in which to
install their own info files, any files which were installed via the
symlink are now lost as far as dpkg is concerned, and it can't clean
them up. This kind of persistent mess is unnecessary, eats disk space,
and is hard to detect without appropriate tools (such as `cruft', which,
in ideal circumstances, would be unnecessary).
Another point about your scheme is that /usr/info becomes useless.
With your scheme, we can never use /usr/info for anything else, because
there's no way of separating /usr/info from /usr/share/info once that
first symlink has been put in place. This might even matter sometime.
For example, /usr/doc might someday be used to contain documentation
which should be different on different architectures. (I don't (yet)
see why that would be useful, but who knows what will happen?)
A better way of handling this transition might be dpkg-divert.
(I'm not _au fait_ with dpkg-divert's details, so I'm not sure how
much it would need to be improved before it could be used like this.)
Assuming dpkg-divert is (modified to be) capable of diverting whole
directory trees, the transition could go like this:
- Packages install man pages and info files in FHS locations. These
packages need not predepend on a version of base-files (IIRC your
scheme needed this), which will help those people who try to upgrade
using an older dselect method which doesn't handle predepends neatly.
These packages could recommend an appropriate version of base-files --
the packages' programs don't stop working if base-files isn't upgraded.
Browsers do not yet need to know those locations.
- Some version of base-files diverts /usr/share/info to /usr/info. In the
process, it moves any files dpkg already installed in /usr/share/info to
/usr/info. (Files installed by other means stay where they were put.)
dpkg has a record of which files are where and, when the diversion
is removed (perhaps done early by a sysadmin who wants the benefit
of having info files shared between architectures), it can replace
everything in its proper place, as per the packages' file lists.
- Browsers are fixed to handle the new locations.
- At some stage, base-files removes the diversion, and everything snaps
back to normal and becomes FHS compliant.
I suppose I'm effectively saying that dpkg-divert should be improved to
do most of what your special-purpose, one-time `fhs-transition' script
would have done, but it'll be more general and, once it's working and
debugged, will be useful in future transitions. A single script written
for this particular transition won't be useful again, except perhaps as
documentation, and probably won't be fully debugged until after everyone
has upgraded.
With this scheme, base-files would need to depend on an appropriate
version of dpkg, but nothing else need depend on a version of base-files.
>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 ?
Maybe. But I think we have the tools to do better than that.
>> 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.
But all the files in, e.g., /usr/share/info actually wind up in /usr/info.
Even though all the packages installed may be FHS compliant, the system
is merely FHS compatible (not FHS compliant (see FHS sec1.8)) until the
sysadmin sits down and takes the time to learn about the transition, read
about our `fhs-transition' script, and decide to invoke it. Some version
of our distribution might be FHS compliant, but upgrading a system to
that version wouldn't make the system FHS compliant. The benefits of
/usr/share are not realised until the sysadmin takes the time to make
it so.
With the scheme I outlined above, the system is FHS compliant as soon
as all of its packages are FHS compliant. The sysadmin never has to sit
down and work on his system to make it compliant and reap the benefits.
Surely this is the purpose of using a distribution?
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
PS: Apologies for subjecting you all to such a long rant...
Reply to: