From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1EpJ9P-0003HU-L1 for garchives@archives.gentoo.org; Thu, 22 Dec 2005 05:38:04 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jBM5bJU0019677; Thu, 22 Dec 2005 05:37:19 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jBM5Ylqr013214 for ; Thu, 22 Dec 2005 05:34:47 GMT Received: from c-67-171-150-177.hsd1.or.comcast.net ([67.171.150.177] helo=[192.168.1.106]) by smtp.gentoo.org with esmtpa (Exim 4.54) id 1EpJ6F-0006nN-0X for gentoo-dev@lists.gentoo.org; Thu, 22 Dec 2005 05:34:47 +0000 Message-ID: <43AA3AF6.6000903@gentoo.org> Date: Wed, 21 Dec 2005 21:34:46 -0800 From: Donnie Berkholz User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051219) X-Accept-Language: en-us, en Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: Gentoo Developers Subject: [gentoo-dev] Annoying X.Org tarball naming (and how to deal with it) X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: d41ef312-d92f-45b8-a6f6-b52159f7805b X-Archives-Hash: b84d4578e1450e065c56d421dbdcfc57 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd appreciate some ideas better than what I've come up with so far to deal with the very strange X.Org release naming. When modular tarballs are part of a full X.Org release (7.0, 7.1, etc), then they are named PN-PV-XORG_RELEASE.tar.(gz|bz2) and S matches. When modular tarballs are independently released outside a full X.Org release, they are named the standard way -- PN-PV.tar.(gz|bz2), same for S. Dealing with this all in an automated fashion in x-modular.eclass is somewhat difficult, and here's what I've come up with: A variable (XORG_PV), set by the ebuild, to tell _which_ release it's part of when it is part of a full release. If it's set, that means (1) it is part of a full release and (2) indicates which release it's part of. What does this mean for the future? All modular X ebuilds that are part of a full release will require XORG_PV to be set. All modular X ebuilds that aren't part of a full release will not require anything new. I'm doing it this way because I expect there to be more packages that aren't part of a full release than ones that are. Please give me your input on this. Thanks, Donnie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDqjr2XVaO67S1rtsRAhlPAKCMvjj82U6sNPpVYsUOnKOsRwAF4QCgibKM Ccs1TnSQbXI66BVpf4P8Ed4= =NFr1 -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list