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)
