FHS layout (was: providing apache2 rpms ?)

[Peter Poeml <po...@suse.de>]

On Mon, Sep 30, 2002 at 11:03:46AM +0100, Thom May wrote:
> > Given that we're doing a "system" install, then, I would suggest that we
> > follow the FHS (http://www.pathname.com/fhs/2.2/), and design a layout.
> > 
> > (altho it would seem the discussion will revolve around whether to drop
> >  everything into /opt or in the standard locations like /usr/sbin)
> > 
> The "Debian" layout should be fine for the latter.

 From a SuSE user's perspective, everybody would indeed be fine with the
Debian layout (thanks to FHS!). Except for two small issues:

 - none of the layouts currently provides paths for 64 bit architectures
   that put libraries into /lib64 and /usr/lib64 instead of /lib and
   /usr/lib.  Note that these architectures can be "biarch". (A seperate
   (otherwise identical) layout could be used for that, that's what we
   do for now anyway [*].) FHS 2.2 provides for lib64 but not for biarch
   systemas, AFAICS.

 - as installbuilddir, /usr/share/apache2/build would fit better IMHO
   (I don't think this configuration stuff is host specific) 

I am glad to see that other distros also use the "apache2" directories
so apache2 can be installed alongside apache1.

We could actually drop the "SuSE" and "Debian" layouts, and possibly
others, from config.layout, and introduce a "FHS 2.2" layout! (I.e. copy
the Debian layout)

How about that? It seems *nearly* possible: the only thing not
standardized by FHS is the server root /var/www, so it might be untimely
to call that layout to be *fully* FHS 2.2 compliant.

 - In an attempt to establish a better place than /var/www, we now use
   /srv/www as server root. Despite the fact that /var/www has been in
   use by many distros for years, a consensus on it could never be
   reached, as I understand it because the purpose of /var is variable
   administrative data and transient files, /var may be mounted noexec,
   and most people do not like the saperation of the executable files
   from the server root to somewhere else (it's not just that CGI's go
   to /usr/lib/cgi-bin, but pages also might contain server side
   includes). If the /srv directory can be settled as de-facto standard
   (it is useful for ftp and other stuff as well) it will find its way
   into the FHS.

But this is quite irrelevant for "Jane User" in building a package, and
no reason for the Apache Group not to provide a spec file.

I as a package maintainer have another issue concerning the layout.  (I
think it's worth to mention it here, because it is certainly beneficial
for apache if the distros present their packages in some "common" or
"standard" way, and maybe we shouldn't do the same thing in five
different ways.)

 - I want to provide more than one MPM, and attach -$mpm_suffix to the
   binary name, as well as to /usr/{include,lib}/apache2 to make them
   coexist. apxs requires some changes, in order to build modules for a
   server with a certain MPM, or for all types of MPMS, and use the
   right flags/locations.

But this is my own stuff, and even though I couldn't just use the Debian
layout for this, it shouldn't stop us from merging the layouts into one
FHS compliant layout.

Peter

PS. Anyone feel free to reply in personal mail for package related
discussion that does not suit this list. 

[*] A note... the "SuSE" layout in config.layout as of 2.0.42 does not
reflect all these issues. (I'll submit a patch when I have moved the
icons and error directories to /usr/share/apache2 -- which I just
learned that from the Debian layout, and which I like.)

-- 
Thought is limitation. Free your mind.