| 1 |
Hello, |
| 2 |
|
| 3 |
After reading the proposal at the wiki and reading the posts regarding this |
| 4 |
project here at the ML I started poking arround and really seeing if this |
| 5 |
project was worth it. |
| 6 |
|
| 7 |
The actual eselect code is deprecated and Exherbo's ecletic is not that |
| 8 |
different and can be slow. Eselect can be a very powerful tool but could be |
| 9 |
improved with a C rewriting. Having this in mind, using |
| 10 |
modules.sf.netproject would be yet another workaround for a common |
| 11 |
problem of gentoo users |
| 12 |
and therefore not the solution. |
| 13 |
|
| 14 |
Besides re-writing eselect in plain C the new implementation would be as |
| 15 |
follows: |
| 16 |
|
| 17 |
Every ebuild with SLOT != 0 would create it's own "module" in a per-system |
| 18 |
DB (similar to /var/db) allowing the module listing and switching easy. This |
| 19 |
implies some coding on portage and a few parameter tweaking on each |
| 20 |
"modulable" ebuild. |
| 21 |
The "module" creation would be automatic and therefore created upon a |
| 22 |
successful emerge. |
| 23 |
Another per-user DB would be maintained and read upon each login for |
| 24 |
environment switching (adding a few lines on /etc/bash.rc or similar). |
| 25 |
The per-user DB would also allow various profiles per user and fast |
| 26 |
switching between them. |
| 27 |
|
| 28 |
Would be glad to hear some comments from other gentoo/list users. |
| 29 |
|
| 30 |
The idea on the wiki "universal select tool" really got into my interest as |
| 31 |
it is a common problem that I have to deal with from time to time. |
| 32 |
|
| 33 |
Cheers, |
| 34 |
Sérgio |
Archives