From owner-freebsd-ports@FreeBSD.ORG Sun Mar 21 14:37:03 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2302A106564A for ; Sun, 21 Mar 2010 14:37:03 +0000 (UTC) (envelope-from tmseck-lists@netcologne.de) Received: from smtp6.netcologne.de (smtp6.netcologne.de [194.8.194.26]) by mx1.freebsd.org (Postfix) with ESMTP id D6B868FC13 for ; Sun, 21 Mar 2010 14:37:02 +0000 (UTC) Received: from wcfields.tmseck.homedns.org (xdsl-89-0-132-187.netcologne.de [89.0.132.187]) by smtp6.netcologne.de (Postfix) with SMTP id 2CEA92A0AC2 for ; Sun, 21 Mar 2010 15:37:01 +0100 (CET) Received: (qmail 81786 invoked by uid 1001); 21 Mar 2010 14:36:52 -0000 Date: Sun, 21 Mar 2010 15:36:52 +0100 From: Thomas-Martin Seck To: freebsd-ports@freebsd.org Message-ID: <20100321143652.GB1784@wcfields.tmseck.homedns.org> References: <20100317184936.2310.qmail@wcfields.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Organization: a private site in Germany X-PGP-KeyID: DF46EE05 X-PGP-Fingerprint: A38F AE66 6B11 6EB9 5D1A B67D 2444 2FE1 DF46 EE05 X-Attribution: tms Subject: Re: correct location for third party /var files X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 14:37:03 -0000 * Doug Barton (dougb@FreeBSD.org): > On Wed, 17 Mar 2010, Thomas-Martin Seck wrote: > >When I started maintaining ports in 2004, the (or at least my) goal was > >to avoid absolute paths in pkg-plist like the plague, that is why I do > >not bother to use something /var/cache/squid or /var/log/squid instead > >of PREFIX/squid/{logs,cache}. There is IMHO nothing wrong with storing > >variable data in $PREFIX/portname/ as long as this is sensibly done. > >$PREFIX/portname/var or $PREFIX/var/portname on the other hand is > >usually just a sign of sloppy porting and should be fixed. > > > >Trying to separate static and variable data and scattering said data > >across filesystems just for the sake of it or for arcane aesthetic > >reasons is - IMO - not really helpful for the user. > > I disagree strongly. hier(7) exists for a reason. I have always set up > systems to make a clear distinction between partitions that will be more > or less "static" and those that will be actively written to. This saves a > lot of time NOT having to rebuild a system after a crash because the > essential elements are still healthy. > > Your personal feelings about it don't really enter in. If you don't > understand or don't agree with a policy feel free to discuss it. Choosing > to ignore it because you don't like it isn't really an option. Oh dear, what did I do. (Why did people not report this five years ago?) Anyway, I just tried to move cache/log/pidfile to /var and found that this seems a bit tricky if not impossible when you generate your packagelist dynamically with PLIST_DIRS/PLIST_FILES. It looks like you need to wrap your absolute paths (or rather the @dirrm(try) calls in the plist) between "@cwd /" and "@cwd %%PREFIX%%". Does anyone know how to achieve this without resorting to a static pkg-plist? (I'd rather not introduce a static pkg-plist file with tons of substitutions for squid-2 and squid-3.0 because of the configurable list of installed error directories but for 3.1 and up this could be doable if there is no other solution. The plan would be to have the cache in /var/squid/cache, logs in /var/log/squid and the pidfile in /var/squid/; this is so that the squid master process does not need root privileges just to be able to write to /var/run.) What I would like to see is a consensus how to handle these kind of issues, especially about what should not be put under $PREFIX and a how-to-do-it in the Porter's Handbook and a mechanism in bsd.port.mk that helps one to achieve this if there isn't one already.