x11 /tmp preparation rc.d script

[Dejan Lesjak]

On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote:
> Dejan Lesjak escribió:
> >Other than that, I don't really know what would be the best way to handle
> >creation of this directories and haven't commented so far, but since I'm
> >already writing (mostly because I thought rc@ list should be CCed), here's
> > my opinion FWIW: the simplest seems to be a patch from Pawel Worach at
> > http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-November/0424
> >45.html The benefit of using this simple approach is that it is simple (of
> > course :) and furthermore it only adds two more directories to /tmp at
> > startup as oposed to adding a file in /etc/rc.d. The difference being one
> > inode. But then again, perhaps I don't see all the implications and this
> > is too simple.
>
> The only I know is that this breaks rcNG writing rules.  This is a
> little more than style.  I think that goin more modular can't hurt.

Well it is certainly an exception to how rcNG scripts are otherwise written, 
but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal 
of X lock file is already there as that seems the right place to do that. 
Because of this it also seems natural (to me at least) to just add creation 
of another dir there. I believe that having this in this script makes things 
done at the right time - if one has configured to have /tmp directory cleaned 
after boot, then things that should be recreated are recreated right after 
that; if no other explicitly ordered cleaning up is done, these directories 
(and a lock file) are still "cleaned" away and recreated with side effect of 
having the right permissions. I'm not opposed of going modular, it just seems 
that going modular for the sake of one directory is a bit of an overkill.

> >Is there a real benefit in creating another rc.d script for doing this and
> >adding a knob to turn creation of these directories off?
>
> Even more critical paths in the boot process are controlled in this
> manner. Why not?

As I said, I'm not opposed of doing it in this manner, I just don't see the 
real need to create several additional scripts instead of changing two lines 
in existing one that already takes care of cleaning (and preparing) /tmp 
directory.

> >Yes of course that would only solve things on -current and -stable,
> > however
>
> This was allways the main problem of solve this 'only base'.
>
> >there is already an UPDATING entry for this and we can always add a script
> > to be installed from a port that would take care of transition period
> > (probably as soon in dependency tree as possible, ie -libraries).
>
> There are PRs on this.  I think that latest rcNG script (with perhaps
> some tweaks to work from ports) installed from Xorg libraries will be
> the better first step.  We may make this install_script conditional when
> we have the problem solved in RELENG_5 base (test OS_VERSION) and lost
> this when RELENG_4 life cycle was expired.

I'm aware of the PRs on this, I wanted to voice my opinion on the particular 
problem of creating a directory /tmp/.ICE-unix with right permissions.
Allow me to ramble a bit more on these: If we go to "modular" way as you put 
it, the we would have to add a script to create ICE-unix directory to, say, 
-libraries ports and a script to remove lock file and X11-unix to -server 
ports (more than two of them), while being careful not to let different 
-server ports (as in server and nestserver...) step onto each others toes. Or 
we could make additional port to only install one rc script. This is 
certainly doable and would of course be more or less modular and could even 
have knobs so one could choose if directories should be created/removed and 
if lock file should be created/removed. I can't help but to think that this 
would be using a bit tooo enormous hammer, that's why I still think a simple 
solution proposed by Pawel Worach would be enough here.

Dejan