| 1 |
> 2) A seperate 'server' portage tree that offered: |
| 2 |
> * only updated quarterly |
| 3 |
> * security and major bug-fixes off-cycle, but no other changes to the |
| 4 |
> tree |
| 5 |
> * guaranteed minimum life of all ebuilds in the tree |
| 6 |
> |
| 7 |
> Which would you find more valuable and why? |
| 8 |
> |
| 9 |
> --kurt |
| 10 |
|
| 11 |
Will only add comments not repeat what others said: |
| 12 |
|
| 13 |
2: |
| 14 |
- A specific profile setting (in make.conf?) pointing to a server profile with server masks limiting the packages in the portage branch. The reason for this is that you don't double the effort of maitaining 2 trees and everyone gets to work in the same direction (no need to duplicat and maitain two ebuilds, they is no reason for them to differ from one system to the other IMHO). |
| 15 |
|
| 16 |
The portage mechanism is excellent, we just need to hold it back from wanting to update everything and I believe a server.mask type of solution would bring the benfits of not duplicating work as well as brigning stability. Also, the "server" profil should be more permissive on keeping old ebuilds that are not a security threat. |
| 17 |
|
| 18 |
Eric |
Archives