| 1 |
On Tue, 2004-02-03 at 11:23, Kurt Lieber wrote: |
| 2 |
> On Tue, Feb 03, 2004 at 10:37:50AM -0500 or thereabouts, Chris Gianelloni wrote: |
| 3 |
> > I still like the idea of separate rsync branches. |
| 4 |
> > |
| 5 |
> > gentoo-2004.0-stable and gentoo-2004.0-updates, both taken via rsync |
| 6 |
> > with -stable being static per release and -updates being dynamic and an |
| 7 |
> > overlay to ensure it always overrides the -stable unless a user emerges |
| 8 |
> > a =cat/ver combo from stable. |
| 9 |
> |
| 10 |
> So if I understand you correctly, you're suggesting having a total of 8 |
| 11 |
> rsync branches: |
| 12 |
> |
| 13 |
> gentoo-2004.0-stable |
| 14 |
> gentoo-2004.0-updates |
| 15 |
> gentoo-2004.1-stable |
| 16 |
> gentoo-2004.1-updates |
| 17 |
> ... |
| 18 |
> gentoo-2004.3-updates |
| 19 |
> |
| 20 |
> Is that correct? |
| 21 |
|
| 22 |
That is correct. |
| 23 |
|
| 24 |
> If so, I like the idea in theory, but how do you make sure security fixes |
| 25 |
> get into all the appropriate trees? I can see a huge QA nightmare with |
| 26 |
> devs forgetting to include some critical security fix in the older trees. |
| 27 |
|
| 28 |
The "stable" team would help ensure this. It would take quite a bit |
| 29 |
more work, for sure, but I think the payoff is worth it in the long run. |
| 30 |
|
| 31 |
> Then there's the whole issue of dependencies of security updates that I |
| 32 |
> mentioned in my reply to danarmak. That would still be a problem here. |
| 33 |
|
| 34 |
This could definitely be a problem if we don't get a large enough group |
| 35 |
working on the project. I would think in most cases we would attempt to |
| 36 |
backport patches to the older versions, if possible, and update |
| 37 |
dependencies only as a last resort. It would require a slight change |
| 38 |
into our GLSA's to include information about the dependencies. The main |
| 39 |
function of the "stable" tree is to provide a much more static target |
| 40 |
for users who wish to have a "standardized" environment. By listing |
| 41 |
dependencies, the administrator would be able to test the changes before |
| 42 |
making them in his environment. |
| 43 |
|
| 44 |
> We could write a whole crapload of logic into repoman so it could help with |
| 45 |
> this, but that's a lot more invasive than I had planned on this GLEP being. |
| 46 |
|
| 47 |
I agree. I don't think repoman should take care of it beyond possibly |
| 48 |
checking to make sure all items directly in DEPEND/RDEPEND for a given |
| 49 |
package are marked stable when the package is marked stable. |
| 50 |
|
| 51 |
I think the best way to do this would be to have a good team working on |
| 52 |
the project. Security updates are always something that needs to be |
| 53 |
taken very seriously and there are a lot of very talented people out |
| 54 |
there. I don't think we would have a problem finding people if we |
| 55 |
needed help. The Gentoo community is just awesome for such things. |
| 56 |
|
| 57 |
> That said, I do like the idea if you can help me understand how it's |
| 58 |
> manageable without being overly cumbersome to implement. |
| 59 |
|
| 60 |
Honestly, I don't know that this is something that we could do at the |
| 61 |
moment, but it seems like it would be a great thing to shoot for as a |
| 62 |
goal. This would also be the perfect platform for a "boxed" Gentoo, as |
| 63 |
it would be much more like a "traditional" distribution in releases, yet |
| 64 |
still offer much of the power and flexibility of Gentoo. There could |
| 65 |
also be a fairly easy transition to the "other" Gentoo via a simple |
| 66 |
make.conf setting. |
| 67 |
|
| 68 |
Making the current portage tree into a -current would be very feasible. |
| 69 |
This would have -current being the way things are now, and the release |
| 70 |
trees being the more frozen tree. |
| 71 |
|
| 72 |
Like I said before, it *is* a long road and a ton of work, but I think |
| 73 |
it would make for an excellent roadmap for Gentoo's future without |
| 74 |
compromising people's wishes for where Gentoo is going and also for |
| 75 |
where it is now. |
| 76 |
|
| 77 |
> > Dual portage trees requires no portage changes as portage supports |
| 78 |
> > multiple overlays now. |
| 79 |
> |
| 80 |
> OK, good to know. I wasn't sure if this was fully functional yet. That |
| 81 |
> said, is it easy to use? Can I type "emerge sync --updates-overlay" or |
| 82 |
> something similar? If we're expecting users to use rsync directly, then I |
| 83 |
> think that's probably unrealistic. |
| 84 |
|
| 85 |
I haven't used it much yet, but I think something like possibly an |
| 86 |
"updates" keyword for emerge would work wonders. |
| 87 |
|
| 88 |
"emerge sync/rsync" for the /usr/portage tree, be it -current or |
| 89 |
-2004.0, etc and a "emerge updates" for updating the releases. The |
| 90 |
emerge updates could perform the same function as emerge sync when |
| 91 |
running on a -current tree. |
| 92 |
|
| 93 |
-- |
| 94 |
Chris Gianelloni |
| 95 |
Developer, Gentoo Linux |
| 96 |
Games Team |
| 97 |
|
| 98 |
Is your power animal a pengiun? |
Archives