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: Thomas Orgis <thomas-forum AT orgis.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] smgl-fhs proposed update
  • Date: Mon, 1 Jan 2007 12:37:08 +0100

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).
It will also fail to do so for any direct network mount on that place, unless
root squashing is off - what would be a bad idea.
So one could make a general discussion out of this with arguing about
"system" dirs being network mounts and what smgl should care about and what
not...
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.
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.
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.


Alrighty then,

Thomas.




Archive powered by MHonArc 2.6.24.

Top of Page