From owner-freebsd-x11@FreeBSD.ORG Wed Jan 12 17:10:08 2005 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A7F816A4CE; Wed, 12 Jan 2005 17:10:08 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD8B143D31; Wed, 12 Jan 2005 17:10:06 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (localhost.ijs.si [127.0.0.1]) by niobe.ijs.si (Postfix) with ESMTP id 70F6D1DD58B; Wed, 12 Jan 2005 18:10:05 +0100 (CET) Received: from niobe.ijs.si ([127.0.0.1]) by localhost (niobe.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79118-12; Wed, 12 Jan 2005 18:09:48 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id D46961DD476; Wed, 12 Jan 2005 18:09:47 +0100 (CET) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by metatron.ijs.si (Postfix) with ESMTP id EC7631C0071F; Wed, 12 Jan 2005 18:09:46 +0100 (CET) From: Dejan Lesjak To: Jose M Rodriguez Date: Wed, 12 Jan 2005 18:09:45 +0100 User-Agent: KMail/1.7.2 References: <1105321614.8452.54.camel@leguin> <200501102003.35785.dejan.lesjak@ijs.si> <41E2DD07.6010607@redesjm.local> In-Reply-To: <41E2DD07.6010607@redesjm.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200501121809.46129.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-rc@freebsd.org cc: freebsd-x11@freebsd.org cc: x11@freebsd.org Subject: Re: x11 /tmp preparation rc.d script X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:10:08 -0000 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