Gentoo Archives: gentoo-dev

From: Jason Stubbs <jstubbs@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Dynamic SLOTs
Date: Sat, 31 Jul 2004 04:06:46
Message-Id: 200407311309.53381.jstubbs@gentoo.org
1 Hi all,
2
3 Working on SLOT upgrades and the like, I'm having trouble working around
4 dynamic SLOTs - not so much how to do it, but how to get accurate information
5 regarding the SLOT that an ebuild is in. For SLOT upgrades to work, portage
6 needs to know what SLOT a package is in and why it is in that SLOT.
7
8 I'm sure that most of you know already, but I'll quickly go over the issue for
9 those that don't. Portage caches ebuilds. Users get a prebuilt cache from an
10 rsync server. Some ebuilds set variables based on the environment. When users
11 run portage, it uses information based on the environment of the rsync
12 server.
13
14 In terms of SLOTs, we currently have four types of ebuilds:
15
16 * Static in the context of the ebuild (SLOT="${PV}" et al)
17 * Mapped directly on to the kernel (SLOT="${KV}")
18 * Based on a user set variable (SLOT="${CCHOST}-3.2")
19 * Decided on the basis of other software (SLOT="${APACHEVER}")
20
21 The first is obviously not an issue. I added support for USE-based SLOTs to
22 support the third and fourth. I'm not sure what to do about the second. Three
23 possibilities:
24
25 * Find a solution to the specific ${KV} case.
26
27 Ugly. So ugly in fact, I've dropped USE-based SLOTs again.
28
29 * Find a general solution to dynamic SLOTs.
30
31 The general solution proposed thus far has been a RESTRICT="cache". Doing a
32 quick test to compare the performance, I found that sourcing the ebuild is
33 roughly 400 times slower than going to cache. Not really acceptable.
34
35 * Make SLOTs static and find an alternate solution.
36
37 My preferred solution as SLOT upgrades are ridiculously complex when there's a
38 number of disparate factors affecting the SLOT of a package - still quite
39 difficult when it's only USE affecting it.
40
41 Only five ebuilds in total have dynamic SLOTs that aren't ${KV} - gcc,
42 libstdc++, mod_php, mod_scgi and mod_pcgi2. These could all be changed to
43 install all the different versions in one merge. Using the mod_php ebuild as
44 an example, it could build and install files for apache1, reconfigure and
45 then build and install files for apache2 in one go if both USE flags are set.
46
47 As for ${KV}, a better solution for the short term would be RESTRICT="clean".
48 It would at least describe what we actually have at the moment. For the long
49 term, I think something like FEATURES="kernelmodule" or some such would be
50 much more appropriate to the task.
51
52 Thoughts? Flames? Yells for a GLEP?
53
54 Regards,
55 Jason Stubbs
56
57 --
58 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] Dynamic SLOTs Mike Frysinger <vapier@g.o>
Re: [gentoo-dev] Dynamic SLOTs Jason Stubbs <jstubbs@g.o>