Date: Wed, 12 Jan 2005 18:09:45 +0100 From: Dejan Lesjak <dejan.lesjak@ijs.si> To: Jose M Rodriguez <josemi@freebsd.jazztel.es> Cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script Message-ID: <200501121809.46129.dejan.lesjak@ijs.si> In-Reply-To: <41E2DD07.6010607@redesjm.local> References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 10 of January 2005 20:52, Jose M Rodriguez wrote: > Dejan Lesjak escribi=F3: > >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/04= 24 > >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 o= ne > > 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= ,=20 but I don't see this as a bad thing. Creation of /tmp/.X11-unix and removal= =20 of X lock file is already there as that seems the right place to do that.=20 Because of this it also seems natural (to me at least) to just add creation= =20 of another dir there. I believe that having this in this script makes thing= s=20 done at the right time - if one has configured to have /tmp directory clean= ed=20 after boot, then things that should be recreated are recreated right after= =20 that; if no other explicitly ordered cleaning up is done, these directories= =20 (and a lock file) are still "cleaned" away and recreated with side effect o= f=20 having the right permissions. I'm not opposed of going modular, it just see= ms=20 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 a= nd > >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= =20 real need to create several additional scripts instead of changing two line= s=20 in existing one that already takes care of cleaning (and preparing) /tmp=20 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 scri= pt > > 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 particula= r=20 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 pu= t=20 it, the we would have to add a script to create ICE-unix directory to, say,= =20 =2Dlibraries ports and a script to remove lock file and X11-unix to -server= =20 ports (more than two of them), while being careful not to let different=20 =2Dserver ports (as in server and nestserver...) step onto each others toes= =2E Or=20 we could make additional port to only install one rc script. This is=20 certainly doable and would of course be more or less modular and could even= =20 have knobs so one could choose if directories should be created/removed and= =20 if lock file should be created/removed. I can't help but to think that this= =20 would be using a bit tooo enormous hammer, that's why I still think a simpl= e=20 solution proposed by Pawel Worach would be enough here. Dejan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200501121809.46129.dejan.lesjak>