Re: FHS - transition
On Thu, 15 Oct 1998, Ian Jackson wrote:
> > We have discussed this before, but it seems that you missed the discussion
> > at all: If man and info are modified so that they support both old and new
> > locations, we will not have to symlink anything, and we will not need to
> > copy a lot of files from a directory to another one. Just upgrade packages
> > incrementally and the ones being FHS-compliant will have already the files
> > in /usr/share.
>
> This will mean that in order to read manpages from new packages it
> will be necessary for the user to use a new manpage program.
Exactly.
Better having to upgrade the manpage program than upgrading base-files,
which has nothing to do with manpages.
> This is
> precisely the kind of incompatibility I want to avoid.
I don't think anything really bad will happen if we modify info and man
for Debian 2.2 so that they accept both FSSTND and FHS locations and wait
for Debian 3.0 to be fully FHS compliant.
This way the user would only need to install "a new version of the manpage
program" if he/she is using Debian 2.1 and wants to install a certain
package from Debian 3.0. This is unlikely to happen.
> My scheme works fine if you don't want to copy things. We can just
> leave them in the old place, with a symlink, forever, if we want.
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.
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.
For this reason I'm definitely think that making symlinks from the *new*
place to the *old* one in the FHS transition (first item in your
proposal) is not a good idea.
However, making symlinks from *some* of the *old* place to the *new* ones
is not such a bad idea, and I'm really considering it.
What I have in mind is this:
* For info:
base-files_2.1 does not have /usr/info anymore but /usr/share/info.
Its postinst checks for the existence of /usr/info and if it is a real
directory it moves its contents to /usr/share/info.
If /usr/info does not exist yet, then base-files is being installed
by the boot-floppies script to make the base2_1.tgz base system. In this
case there is nothing to move.
Last line in base-files postinst would then create a symlink from
/usr/info to /usr/share/info, so that dpkg follows the symlink for all
newly installed packages.
This would make modifying the info program unnecessary, and also I would
not have to coordinate with the info maintainer about the /usr/info/dir
file, which base-files has to create if it does not exist (how will
base-files know where to create the default dir file if the info program
is able to read two different (real) directories?).
Moreover (this is important), /usr/info/* is not usually very large.
* For man:
base-files_2.1 would have both /usr/share/man and /usr/man as real
directories.
As far as I know, no modification is required in our standard man program
itself, because its behaviour is driven by a configuration file,
/etc/manpath.config. So we could have both /usr/share/man and /usr/man at
the same time and nothing bad would happen. We would only need the mandb
package to be modified so that its default config file includes the old
and the new locations.
Summary: With a very little change in base-files and a very little change
in mandb, we could make Debian 2.1 to be the first Debian release
to support FHS-paths for manpages and info files, so we could make policy
for Debian 2.2 that all manpages and info files should be already
installed in the new locations.
What do others think about this?
--
"32499857f009b9b64b41f10cd74b34c7" (a truly random sig)
Reply to: