Samba 2.0.7 and FHS conventions

[David Lee]

On Fri, 26 Jan 2001, Steve Langasek wrote:

> On Fri, 26 Jan 2001, David Lee wrote:
> 
> > I like the general idea, to ease introduction of this.
> 
> > But could I suggest that the detail be more closely related to the GNU
> > variables for this purpose?  For instance: 
> 
> > >    - SBINDIR becomes ${exec_prefix}/sbin
> > shouldn't that be ${sbindir}
> 
> [etc]
> 
> Agreed.  The big issue here is not whether Samba uses a private directory
> (/usr/local/samba) or scatters its files throughout the root directory; that
> can always be fixed with --prefix.  The issue is that Samba currently doesn't
> sanely map its installed files to the respective autoconf directory variables.
> E.g., config files are stored in $(LIBDIR) rather than ${sysconfdir}, which
> makes it difficult to send your config files to a different directory from the
> shared libraries... definitely an issue now that libsmbclient is in progress.

Exactly.  I'm no expert on either the GNU autoconf variables or the FHS
definitions.  The point of principle I was heading towards was that to
avoid discussing:
   "Samba's feature 'X' should be FHS directory '/Z'"
and rather discuss:
   "Samba's feature 'X' should map to autoconf '$Y'".

Hopefully (though I'm no expert), autoconf's '$Y' is reasonably close to
FHS '/Z', but in case of divergence (which might lead GNU sites to prefer
one set of defaults and FHS sites to prefer another) I then added: 

> > Then perhaps we need:
> >    --enable-compliance={fhs|gnu}
> 
> > The "gnu" variant would allow us to take GNU defaults (and allow
> > GNU-like override flexibility).
> 
> > The "fhs" option would adjust the GNU-set defaults for FHS compliance
> > (again allowing individual override).
> 
> > I suspect this would gain us great flexibility with three main options
> > (1) "traditional" Samba  (2) GNU flavour  (3) FHS flavour.

Perhaps the full form of an "--enable-compliance" feature would be:
   --enable-compliance={gnu|fhs|backward-compatibility}

defaulting to "gnu", having "fhs" as an acceptable alternative and perhaps
issuing a deprecation/expiry-notice warning on "backward-compatibility".
(A site can choose its preferred compliance model then use "--exec-prefix"
etc. for fine-tuning...)

> FHS flavor is really a subset of 'GNU' flavor, in that they share common
> definitions for the /types/ of directories needed and disagree only in the
> default locations assigned to each directory.

Good summary.  That's exactly the sort of principle my long-windedness was
meanderingly bumbling towards.  Concentrating discussion on location
*types* rather than exact values. 

-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 374 2882                  U.K.                  :