Date: Thu, 13 Jan 2005 03:27:16 +0100 From: Jose M Rodriguez <josemi@freebsd.jazztel.es> To: Dejan Lesjak <dejan.lesjak@ijs.si> Cc: Jose M Rodriguez <josemi@freebsd.jazztel.es> Subject: Re: x11 /tmp preparation rc.d script Message-ID: <41E5DC84.60608@redesjm.local> In-Reply-To: <200501121809.46129.dejan.lesjak@ijs.si> References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> <200501121809.46129.dejan.lesjak@ijs.si>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41E5DC84.60608>