| 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 |
Archives