x11 /tmp preparation rc.d script

[Jose M Rodriguez]

Dejan Lesjak escribió:

>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
>
>
>  
>
This is really a classic issue.  Of course, you may choose, but what you 
like as a X11 hacker may not be so good for a rc hacker.

In this aspect, going modular is more a system eng. need.

It's not so direct think that a 'cleartmp' component is so vital for 'x11'.

Also, as this is done in cleartmp,  you don't have  a checkyesno control 
over the code, as  you have in common rcNG  scripts.  This is exec 
'fully inconditional'.

What I don't like is add even more params to this without control, but I 
don't have objetions to maintain the hack with the new needed  support.

--
  josemi