Re: "goals" for slink: FHS
> I think we have agreed to move toward FHS compliance, starting with
> slink. I have looked at the FHS (http://www.pathname.com/fhs/), and
> have a few proposals:
I think that's a good idea, yes. We need to get this started soon, though,
perferrably by the end of this week.
> The first major change I see is that documentation has moved to
> /usr/share. To accommodate this, I suggest we take the following
> steps:
>
> 1. Change the policy to specify man pages in /usr/share/man, info
> pages in /usr/share/info, and miscellaneous docs in /usr/share/doc.
> (Who is maintaining the policy now?)
>
> 2. Modify the man and info readers to look for files in
> /usr/share/{man,info} in addition to the current places. Likewise
> info2www, man2html, dhelp, and dwww.
>
> 3. Modify install-info (from the dpkg package) to work with files
> in /usr/share/info as well as /usr/info (that is, maintain a "dir"
> file in each directory). Likewise, modify dhelp_parse to generate
> its index in /usr/share/doc/HTML.
>
> 4. Modify debhelper and debmake to put man and info files in
> /usr/share/{man,info}, and miscellaneous docs into /usr/share/doc.
>
> 5. Ask developers to start using the new locations, and update the
> manpages* packages.
>
> 6. Modify lintian to issue a warning for documentation outside
> /usr/share.
>
> 7. (much later) Change the lintian warning to an error.
>
> I think the steps have to be done in pretty close to this order. I
> may have missed some steps, though. In particular, I don't know how
> HTML docs are handled.
>
> I am not proposing that we have to complete all these steps, let alone
> convert all our packages, before releasing slink. In fact, a mixed
> system will be somewhat awkward. Maybe we should get slink released
> before we go to step 4.
Good list. I think 1-3 need to be done before doing #4, but some people
do development off of a stable system so it would be nice to do #4 before
the relase of Slink.
> The other major change I see is that /var/lib is deprecated, in favor
> of /var/state. That means of course that all the dpkg state files get
> moved, which I suspect will have endless ramifications. The FHS does
> allow for some leeway, though:
>
> 5.11 ... /var/lib is deprecated, but it may be used in parallel
> with the required /var/state hierarchy, as a transitional measure
> for application-specific data. Note, however, that this allowance
> will be removed in a future release of the standard. Alternately,
> /var/lib may be made a symbolic link to /var/state.
>
> Maybe we should use that symbolic link option for a while, at least.
It might be better to have dpkg move all its files and then create
a /var/lib/dpkg symlink (instead of all of /var/lib).
> I believe we will take exception to these parts of the FHS, and I
> think we should adopt some official statement to that effect:
>
> 6.1.5 /usr/include : Header files included by C programs
>
> These symbolic links are required if a C or C++ compiler is installed.
>
> /usr/include/asm -> /usr/src/linux/include/asm-<arch>
> /usr/include/linux -> /usr/src/linux/include/linux
I think the "asm" and "linux" directories should be real instead of
symlinks since we don't require the presence of the linux source. What
about making them "alternatives" that would point to /usr/src/linux
if the kernel-source package was installed?
Brian
( bcwhite@verisim.com )
-------------------------------------------------------------------------------
Don't marry someone you can live with. Marry someone you can't live without.
Reply to: