| 1 |
Spider <spider@g.o> writes: |
| 2 |
|
| 3 |
> [snip] |
| 4 |
|
| 5 |
> We had to scrap both Gentoo -and- Debian stable trees. Why? Because |
| 6 |
> both update the -main- repository when releasing security fixes/ |
| 7 |
> bugfixes. Neither have a stable tree thats archived once and never |
| 8 |
> changes. |
| 9 |
|
| 10 |
> If you have to actively change a tree (modifications directly into the |
| 11 |
> "frozen" tree) which is the case in many environmens, you get stuck with |
| 12 |
> this problem. if upstream ever changes their tree, work is lost. You can |
| 13 |
> separate local trees and so on, however, once again work is lost when |
| 14 |
> internal revisions have superceeded the ones in the tree. (fex, local |
| 15 |
> changes to sshd to patch ther initscripts and default config files |
| 16 |
> before rollout, which ups the revision of openssh a few times, and then |
| 17 |
> there is a backported securityfix? It won't get merged. ) |
| 18 |
|
| 19 |
If you want a tree that doesn't change, you can simply not update it |
| 20 |
(from the Gentoo mirrors). This is particularly easy if you are running |
| 21 |
your own internal rsync mirror, since then you don't even have to worry |
| 22 |
about not having a convenient mechanism for distributing the portage |
| 23 |
tree to the users. This requires no work from Gentoo -- what does |
| 24 |
require significant work, and what some users want, is a tree that is |
| 25 |
only updated with bug fixes. |
| 26 |
|
| 27 |
|
| 28 |
-- |
| 29 |
Jeremy Maitin-Shepard |
Archives