Public SourceMage Discussion List

["David Brown" <dmlb2000 AT gmail.com>]

On 1/1/07, 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).
> 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...

I understand this I could see having smgl-fhs not do anything since
when it fails (and since its a dependancy for most of the stuff in
basesystem) then the basesystem upgraded spell fails because the spell
couldn't make or ch{mod|own} a directory.  This seems silly and
prevents the administrator of the computer from going outside the fhs
to perform similar tasks as stated above.

> 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.

Thanks that maybe what I end up doing.  Just wanted to submit
something to start getting a discussion going.

- David Brown