Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] smgl-fhs proposed update

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] smgl-fhs proposed update
  • Date: Wed, 24 Jan 2007 14:41:54 -0600

On Jan 01, Thomas Orgis [thomas-forum AT orgis.org] wrote:
> Am Sun, 31 Dec 2006 16:33:08 -0800
> schrieb "David Brown" <dmlb2000 AT gmail.com>:
>
> > Okay I know there was discussion a while back about moving to fhs 2.3
>
> I got a serious issue with smgl-fhs recently and had to disable it to get
> further with a rebuild.
> Consider a setup of a workstation in a bigger network and part of that is
> having many network mounts - one of which being the mailboxen.
> I am using the automounter that manages mountpoints under /mnt/auto and
> that is my /var/spool/mail:
>
> lrwxrwxrwx 1 root root 14 29. Dez 15:02 /var/spool/mail ->
> /mnt/auto/mail
>
> smgl-fhs wants this to be a directory, I made it a symlink to work with
> the automounter setup. Now smgl-fhs fails because it cannot do chmod on
> this (especially when the mount is not active and so the symlink points
> into nowhere).

The obvious fix here is that smgl-fhs should have a '[ -e ... ] ||' before
the mkdir in fhs_mkdir().

> But in this special case: I don't see /var/spool/mail in FHS 2.3 or 2.2
> at all. I see /var/mail.

See http://bugs.sourcemage.org/show_bug.cgi?id=8653#c12 for the rationale
for having /var/mail link to /var/spool/mail instead of the other way
around. I think he makes a valid point but maybe it needs more discussion.

> While FHS won't stop us here from using /var/spool/mail since it is this
> dir on every workstation since many years, dropping it from smgl-fhs
> would actually serve the purpose of letting me do with it what I want.
>
> I am wondering if this conflict that I have with self-managed
> /var/spool/mail could arise on other dirs and if there may be the general
> with to optionally tell the smgl-fhs spell to do nothing, or tell it to
> accept existing dirs as they are and not try to change the
> ownership/perms.

It should probably leave existing things alone; it may break later spells
but this is the local admin's problem.

> Typically, we want to setup the dirs once and if for some reason the
> permissions / ownerships are differing from what smgl-fhs wants there
> could indeed be a reason...
>
> > Attached is a patch for what I'd like to submit, comments are welcome.
>
> one trivial one:
> +config_query FHS_2_3 "be fhs 2.3 complient?" n &&
> isn't that supposed to read "compliant"?
>
> And, I think the optional dirs should presented in a list (multiple)
> choice. One may want /var/account but not /var/games (esp. on a
> workstation for hiding any hint to games on that box;-); or I would like
> to drop /var/mail to prevent user confusion.
> The user should have full choice about the optional dirs. We already
> press FHS, we don't have to press a specific preselection of optional
> dirs.

Agreed. I commented to this effect in http://bugs.sourcemage.org/13112
when I was looking at the smgl-fhs bugs last night.

Attachment: pgphsHjJGvCXJ.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page