| 1 |
Some followups and suggestions: |
| 2 |
|
| 3 |
For the documented portage API: |
| 4 |
I don't mind it being in python, although c/c++ would be nice sometime down |
| 5 |
the road. This is a must for all the stuff karltk calls Gentool.Configure. |
| 6 |
At least, I wish for a short summary of the portage.py api. I tried reading |
| 7 |
it through; there are no comments at all. |
| 8 |
|
| 9 |
For the ebuild review team: |
| 10 |
They could have several separate Gentoo installs. Maybe in chroots. |
| 11 |
One would be empty (emerge system only), good for checking depends. Ebuilds |
| 12 |
are unmerged once they are confirmed to be working. |
| 13 |
Another would have all existing ebuilds installed, good for checking |
| 14 |
conflicts. It would also have all revs installed, good for checking upgrades |
| 15 |
and different dep version scenarios. |
| 16 |
We could have [at least] two devs on the team, one for each of these configs, |
| 17 |
running emerges in the background whenever they aren't using the cpu. Say on |
| 18 |
non-main machines. |
| 19 |
Of course, there'll probably also be a more standard testing machine. |
| 20 |
|
| 21 |
For the ebuild layout (Martin's wish): |
| 22 |
IMHO one of the best things here, beyond guides and docs, is eclasses. They |
| 23 |
ensure maximum standardization, and a lot of other fun things too. |
| 24 |
|
| 25 |
-- |
| 26 |
|
| 27 |
Dan Armak |
| 28 |
Gentoo Linux Developer, Desktop Team |
| 29 |
Matan, Israel |
Archives