Making the Info system FHS-compliant
How to make the Debian info system FHS-compliant.
================================================
Background:
==========
Mandated by the FHS standard, the system should keep the info files in
/usr/share/info rather than /usr/info, "some day in the future".
The way to do this may depend on the degree of compliance or
compatibility with respect the FHS we want to achieve.
I will quote some paragraphs from the FHS:
An implementation is fully compliant with this standard if every
requirement in this standard is met. Every file or directory which is
part of the implementation must be located as specified in this
document. If the contents of a file are described here the actual
contents must correspond to the description. The implementation must
also attempt to find any files or directories (external to itself)
primarily or exclusively in the location specified in this standard.
An implementation is fully compatible with this standard if every file
or directory which it contains can be found by looking in the location
specified here and will be found with the contents as specified here,
even if that is not the primary or physical location of the file or
directory in question. The implementation must, when it attempts to
find any files or directories which are not part of it, do so in the
location specified in this standard, though it may also attempt to find
it in other (non-standard) locations.
An implementation is partially compliant or compatible if it complies
with or is compatible with a significant subset of this document.
[...]
If we have to choose between being fully compliant and being
fully compatible (assuming that we are technically able to achieve both
goals), I think we should go for full compliance on the long term, and not
only compatibility.
Moreover, if we can, we should not only aim for FHS compliance
for the complete system, but also for each individual piece of it
(i.e. for each Debian package individually).
For these reasons, I think that dealing with this by using symlinks is not
a good idea, not to mention that, currently, once dpkg has installed files
from a given package by following a symlink, it is difficult to install a
version of the same package which has the files in the real destination
directory, or viceversa.
Current status:
==============
- The info reader is already able to look for info pages at either
/usr/info or /usr/share/info. The index file `dir' may be at either place.
Only one index file is needed for all pages.
I don't think we want two index files during the transition period. Info
display things separately when there are two index files, and I think we
should try to make this change as transparent as possible for the end
user. For this reason, in what follows, I assume that we will want just a
single index file during the transition period.
- The /usr/sbin/install-info perl script, from dpkg, says:
$infodir='/usr/info';
It updates the index `dir' file at /usr/info and get very upset
if it's not there.
- Currently, a package could install its info files in /usr/share/info and
call install-info by telling it where the info files actually are, and
everything would work. The new info files would be placed at
/usr/share/info but they would be indexed at /usr/info/dir.
- base-files installs a default index `dir' file at /usr/info
if it does not exist in /usr/info.
So, it seems that packages may start to use /usr/share/info right
now, and the *only* remaining problem would be how to move the index file
appropriately.
Ok, time to do some proposals:
Proposal 1:
==========
*) We do the info FHS transition on a per-package basis. There will be a
transition period in which some packages in the distribution will be
following FSSTND (/usr/info) and some others FHS (/usr/share/info).
Proposal 2:
==========
*) Only one index file will be used during the transition period.
Proposal 3:
==========
*) We allow packages in potato to put their info files at /usr/share/info.
Now, to move the index file appropriately, we could do the following:
First, we should forbid the use of the hardcoded install-info's --infodir
option in all maintainer scripts. This is really evil, because it does not
allow us to change the location of the index file in a centralized place,
i.e., by telling the install-info script itself (internally) to use a
different location.
[ BTW: Is there a lintian check for the use of the --infodir option?
If there is not, maybe there should be, because the example in policy
about registering info docs does not use the --infodir option ].
Only when we are sure that we have get rid of all these harcoded and
uneeded --infodir options (which should probably be treated as important
bugs), we move the index file in this way:
\begin{proposal for the move of the index file}
1. base-files is modified so that its postinst creates the dir file in
/usr/info when it does not exist in /usr/info *and* it does not exist in
/usr/share/info either.
The dir file should not be created by default in /usr/share/info
until we are sure that install-info will manage it and no other packages
will try to use /usr/info/dir in a hardcoded way.
Proposal 4:
==========
*) We don't go any further until there are packages in the distribution
left which use a hardcoded install-info's --infodir option.
This means that if this does not already happen in slink, we do what
follows in the distribution after potato, not in potato.
2. After the new base-files package which does not create an index
file when there is one already at /usr/share/info has been installed
in potato, we modify dpkg in two ways:
a) Its postinst moves /usr/info/dir to /usr/share/info/dir.
b) At the same time, its install-info script is modified so that
it reads $infodir='/usr/share/info';
For the unlikely case that the user installs this dpkg and *reinstall*
the base-files package in slink, we make this dpkg to depend on the
previous base-files package by using a ">=".
3. After /usr/share/info is officially the "right" place for the index
file, base-files is modified so that it install the default index file
in /usr/share/info if it does not exist in /usr/info or /usr/share/info.
Why still the "/usr/info" part? Because otherwise, in an upgrade from
slink to potato, it may happen that base-files is upgraded and configured
*before* the new dpkg. In such case the system would end up having two
index files, one at /usr/info, another one at /usr/share/info.
Does this base-files have to depend on the new dpkg by using a ">="?
It seems not:
- If base-files is upgraded from slink or from any other previous Debian
release, since there will always exist a dir in /usr/info or
/usr/share/info, none will be created.
- If base-files is installed by the boot-floppies package to create the
base system for potato, the boot-floppies package will use both the new
base-files and the new dpkg, and the location of the index file will be
/usr/share/info.
4. *After* potato is released, we change base-files again so that,
finally, it installs the default index file in /usr/share/info if it does
not exist in /usr/share/info.
We could make this base-files to Depend on the dpkg in potato to make sure
that people upgrading from hamm to the release after potato will not have
any problem.
\end{proposal for the move of the index file}
Comments?
Thanks.
--
"8fa7accfb529f50f1943de781e5878d3" (a truly random sig)
Reply to: