Re: [Groff] Macro path and /usr/local

[Colin Watson]

On Sun, May 05, 2002 at 08:33:08PM -0500, P. Alejandro Lopez-Valencia wrote:
> At 01:52 a.m. 06/05/2002 +0100, Colin Watson wrote:
> >Since I build with --prefix=/usr, libprogramdir is /usr/lib/groff while
> >dataprogramdir is /usr/share/groff. I have to say that I can't think of
> >any plausible reason for platform-dependent (does this mean
> >architecture-dependent?) macros, and I think localtmacdir ought to point
> >to something in /usr/local. Can anyone clarify the intent of these
> >comments for me?
> 
> If you use a vendor unix there is a high probability that you already have 
> a version of DWB installed, no matter how lobotomized it be. As your manual 
> pages depend on that version of DWB, you don't want to foobar it blindly 
> overwriting it with groff. Yet, you do want to wrap those macros for use 
> with groff in compatibility mode.

Um, does DWB use */groff? If not, it won't clash.

Anyway, in the case of Debian I'm not too worried about /usr/share
clashes with vendor Unixes. I'm prepared to bet that it wouldn't work
anyway for a host of other reasons.

> >What would people think about moving systemtmacdir to
> >/usr/share/groff/site-tmac and localtmacdir to
> >/usr/local/share/groff/site-tmac? This is consistent with how I
> >understand the FHS, but, if any other packagers are reading this list,
> >I'd be interested to hear what you do.
> 
> In my experience "share" directory hierarchies are those you put under 
> automount control (or whatever remote file-system export technology you 
> decide to use) for cluster sharing and the "lib" hierarchy is the 
> appropriate place for system dependent files. A proposal to use the "etc" 
> or the "var" hierarchies would have a better chance of flying.

Well, these are the definitions in the FHS:

       4.4  /usr/lib : Libraries for programming and packages

       /usr/lib includes object files, libraries, and internal binaries that
       are not intended to be executed directly by users or shell scripts.

       [...]

       Miscellaneous architecture-independent application-specific static files
       and subdirectories should be placed in /usr/share.

       4.7  /usr/share : Architecture-independent data

       The /usr/share hierarchy is for all read-only architecture independent
       data files.

In fact, the FHS specifically mentions groff as a recommended
subdirectory of /usr/share, so I plan to leave that the way it is.

Choosing between /usr/local, /etc, and /var depends on whether you
believe macros are architecture-independent data, configuration files,
or variable data (!).

-- 
Colin Watson                                  address@hidden