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 |