From owner-freebsd-x11@FreeBSD.ORG Tue Feb 22 13:31:42 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 597A216A4CE for ; Tue, 22 Feb 2005 13:31:42 +0000 (GMT) Received: from niobe.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F5DD43D5E for ; Tue, 22 Feb 2005 13:31:41 +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 3FECA1DD666; Tue, 22 Feb 2005 14:31:40 +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 75979-09-4; Tue, 22 Feb 2005 14:31:21 +0100 (CET) Received: from metatron.ijs.si (metatron.ijs.si [193.2.4.152]) by niobe.ijs.si (Postfix) with ESMTP id 7FB2D1DD5A7; Tue, 22 Feb 2005 14:31:14 +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 73A9C1C0071C; Tue, 22 Feb 2005 14:31:13 +0100 (CET) From: Dejan Lesjak To: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= Date: Tue, 22 Feb 2005 14:31:12 +0100 User-Agent: KMail/1.7.2 References: <4219D008.6030107@alumni.rice.edu> <86y8dgannw.fsf@xps.des.no> In-Reply-To: <86y8dgannw.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200502221431.12805.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si cc: freebsd-x11@freebsd.org cc: noackjr@alumni.rice.edu Subject: Re: X.Org 6.8.2 - (most probably) final patch 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: Tue, 22 Feb 2005 13:31:42 -0000 On Tuesday 22 of February 2005 11:34, Dag-Erling Sm=F8rgrav wrote: > David Adam writes: > > 17 minutes ~is~ a long time for extraction (particularly over several > > ports) but I think it's a problem best solved by split distfiles, not by > > lower compression. > > > > Is there any way around it (turning off cleaning, unbzip2ing and > > modification of the Makefile/distinfo)? > > One possibility is to create a port that installs a patched source > tree into /usr/X11R6/src/${PORTVERSION}, and have the other ports > BUILD_DEPEND on it and lndir(1) the source code into their WRKDIR. > This would have the added advantage of eliminating the current mess > with random xorg ports nicking patches from eachother. > > DES Excellent idea! I was pondering on how this would handle the case where a patch would need = to=20 be added to single port, say xorg-vfbserver... If a patch would go to this= =20 port then lndir wouldn't help, since it would patch the installed source fi= le=20 (and on next rebuild fail because of previously applied patch). If a patch= =20 would go into this source port, then lndir would work, but there needs to b= e=20 a way for xorg-vfbserver to know that the patch has been applied. I was=20 pondering at first that source port would rather install=20 into /usr/X11R6/src/${PORTVERSION}_${PORTREVISION} and xorg-vfbserver would= =20 depend on this location. But that would require changing all of the other=20 ports to depend on new location of source. I'm now thinking of two=20 possibilities: =2D defining proper src location in xorg-source port Makefile.inc or some s= uch=20 and including this in all xorg- ports =2D installing in /usr/X11R6/src/${PORTVERSION} but with placeholder files= =20 like /usr/X11R6/src/${PORTVERSION}/.foopatch-applied and depending on that= =20 (with proper if(source installed) && !exists(.foopatch-applied) echo=20 "somekindofexplanation") Anyway, this seems doable so far. I'm still hoping that there will be split= =20 distfiles for this release since this upgrade is now quite far, and I'm not= =20 sure whether portmgr will want another test run with such change (the=20 packages contents and installed files should stay the same so this is rathe= r=20 internal xorg- ports change, but configure parts would probably need to be= =20 reworked and all...). Nevertheless, if nobody comes up with a scenario in=20 which this way would fail I think this is the way to go :) I was thinking of doing something to use the same source for all of separat= e=20 ports through using WRKSRC or somesuch, but never thought of actually=20 installing the source. Nifty trick, thanks :) Dejan