| 1 |
On 18:43 Mon 30 Mar , mephx wrote: |
| 2 |
> Besides re-writing eselect in plain C the new implementation would be as |
| 3 |
> follows: |
| 4 |
> |
| 5 |
> Every ebuild with SLOT != 0 would create it's own "module" in a per-system |
| 6 |
> DB (similar to /var/db) allowing the module listing and switching easy. This |
| 7 |
> implies some coding on portage and a few parameter tweaking on each |
| 8 |
> "modulable" ebuild. |
| 9 |
> The "module" creation would be automatic and therefore created upon a |
| 10 |
> successful emerge. |
| 11 |
> Another per-user DB would be maintained and read upon each login for |
| 12 |
> environment switching (adding a few lines on /etc/bash.rc or similar). |
| 13 |
> The per-user DB would also allow various profiles per user and fast |
| 14 |
> switching between them. |
| 15 |
> |
| 16 |
> Would be glad to hear some comments from other gentoo/list users. |
| 17 |
|
| 18 |
What you'll find with C only is that most of our devs won't be able to |
| 19 |
write modules for their own packages because they only know bash and |
| 20 |
maybe some python. A core in C might work, a la openrc, provided you do |
| 21 |
a bit of profiling to show where the holdup is and why it can't be fixed |
| 22 |
in a higher-level language. |
| 23 |
|
| 24 |
-- |
| 25 |
Thanks, |
| 26 |
Donnie |
| 27 |
|
| 28 |
Donnie Berkholz |
| 29 |
Admin, Summer of Code |
| 30 |
Gentoo Linux |
| 31 |
Blog: http://dberkholz.wordpress.com |
Archives