From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25000 invoked from network); 31 Jul 2004 04:06:46 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 31 Jul 2004 04:06:46 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Bql8r-0003bW-Rh for arch-gentoo-dev@lists.gentoo.org; Sat, 31 Jul 2004 04:06:42 +0000 Received: (qmail 15735 invoked by uid 89); 31 Jul 2004 04:06:41 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 28948 invoked from network); 31 Jul 2004 04:06:41 +0000 From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Date: Sat, 31 Jul 2004 13:09:53 +0900 User-Agent: KMail/1.6.82 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200407311309.53381.jstubbs@gentoo.org> Subject: [gentoo-dev] Dynamic SLOTs X-Archives-Salt: 39e43194-a047-4a4c-995a-6fba571421df X-Archives-Hash: 3c62a08b9e657456b230a472d8a76d21 Hi all, Working on SLOT upgrades and the like, I'm having trouble working around dynamic SLOTs - not so much how to do it, but how to get accurate information regarding the SLOT that an ebuild is in. For SLOT upgrades to work, portage needs to know what SLOT a package is in and why it is in that SLOT. I'm sure that most of you know already, but I'll quickly go over the issue for those that don't. Portage caches ebuilds. Users get a prebuilt cache from an rsync server. Some ebuilds set variables based on the environment. When users run portage, it uses information based on the environment of the rsync server. In terms of SLOTs, we currently have four types of ebuilds: * Static in the context of the ebuild (SLOT="${PV}" et al) * Mapped directly on to the kernel (SLOT="${KV}") * Based on a user set variable (SLOT="${CCHOST}-3.2") * Decided on the basis of other software (SLOT="${APACHEVER}") The first is obviously not an issue. I added support for USE-based SLOTs to support the third and fourth. I'm not sure what to do about the second. Three possibilities: * Find a solution to the specific ${KV} case. Ugly. So ugly in fact, I've dropped USE-based SLOTs again. * Find a general solution to dynamic SLOTs. The general solution proposed thus far has been a RESTRICT="cache". Doing a quick test to compare the performance, I found that sourcing the ebuild is roughly 400 times slower than going to cache. Not really acceptable. * Make SLOTs static and find an alternate solution. My preferred solution as SLOT upgrades are ridiculously complex when there's a number of disparate factors affecting the SLOT of a package - still quite difficult when it's only USE affecting it. Only five ebuilds in total have dynamic SLOTs that aren't ${KV} - gcc, libstdc++, mod_php, mod_scgi and mod_pcgi2. These could all be changed to install all the different versions in one merge. Using the mod_php ebuild as an example, it could build and install files for apache1, reconfigure and then build and install files for apache2 in one go if both USE flags are set. As for ${KV}, a better solution for the short term would be RESTRICT="clean". It would at least describe what we actually have at the moment. For the long term, I think something like FEATURES="kernelmodule" or some such would be much more appropriate to the task. Thoughts? Flames? Yells for a GLEP? Regards, Jason Stubbs -- gentoo-dev@gentoo.org mailing list