1 |
On 30-03-2009 18:43:14 +0100, mephx wrote: |
2 |
> Besides re-writing eselect in plain C the new implementation would be |
3 |
> as follows: |
4 |
|
5 |
I don't think C is a necessity (even though it has my preference), and |
6 |
might interfere with some requirements, as Donnie already pointed out. |
7 |
|
8 |
> Every ebuild with SLOT != 0 would create it's own "module" in a |
9 |
> per-system DB (similar to /var/db) allowing the module listing and |
10 |
> switching easy. This implies some coding on portage and a few parameter |
11 |
> tweaking on each "modulable" ebuild. |
12 |
> The "module" creation would be automatic and therefore created upon a |
13 |
> successful emerge. |
14 |
> Another per-user DB would be maintained and read upon each login for |
15 |
> environment switching (adding a few lines on /etc/bash.rc or similar). |
16 |
> The per-user DB would also allow various profiles per user and fast |
17 |
> switching between them. |
18 |
|
19 |
In this approach, would it be possible to just use the (existing) vdb? |
20 |
Tools like portage-utils show that you can search through its contents |
21 |
quickly enough not to even require an index actually. And if the |
22 |
package manager is involved anyway, it can simply write those extra bits |
23 |
you need in the vdb as well, as separate entries. |
24 |
|
25 |
Big question would be, what. Like, how would a thing like gcc-config or |
26 |
binutils-config be implemented like that. How would be the management |
27 |
of different versions of the scripts that handle the actual switching |
28 |
and stuff. |
29 |
|
30 |
|
31 |
-- |
32 |
Fabian Groffen |
33 |
Gentoo on a different level |