1 |
On Tue, 2004-02-03 at 13:58, Paul de Vrieze wrote: |
2 |
> On Tuesday 03 February 2004 16:28, Chris Gianelloni wrote: |
3 |
> > |
4 |
> > db-4.1.25_p1-r3 KEYWORDS="ia64 ppc amd64 ppc64 hppa" |
5 |
> > db-4.0.14-r2 KEYWORDS="x86 sparc alpha mips" |
6 |
> |
7 |
> For this ebuild we might look into moving db-4.1 into stable. In any case I |
8 |
> seriously doubt whether it is wise for non-experimental architectures to mark |
9 |
> ebuilds stable that are not stable for the main arch (x86) (experimental |
10 |
> being the amd64 and ia64 archs) |
11 |
|
12 |
What about packages that do not exist for the "main arch"? I definitely |
13 |
do not consider ANY arch to be the main one, even though x86 is |
14 |
definitely the most widely used. In fact, we need to break ourselves |
15 |
entirely from the idea of a specific arch and work to make as much arch |
16 |
independent work as possible. Duplication of work sucks... |
17 |
|
18 |
> > Now, depending on which arch you'r eon would entirely depend on which |
19 |
> > version you get. |
20 |
> > |
21 |
> > There should be ZERO updates in the actual stable tree. You should be |
22 |
> > able to install a machine on day 1 of the release, or day 89 and still |
23 |
> > get the EXACT same tree, otherwise, it isn't stable. |
24 |
> |
25 |
> Actually I would like to be able to download the tree 10 years from now and |
26 |
> given that the source files are there it should be possible to build a gentoo |
27 |
> system (NOT SECURE, not all hardware) that is the same to one from now. |
28 |
|
29 |
I agree completely. I think the idea is to only keep a year. |
30 |
Personally, I would like to keep the *tree* forever, just only provide |
31 |
fixes for a year (or however long we decide). |
32 |
|
33 |
> > Updates would have to be provided separately, though still via rsync. |
34 |
> > I would see something like /usr/portage-stable and |
35 |
> > /usr/portage-updates, with -stable being static with the release used |
36 |
> > and -updates being all the changes since release. |
37 |
> > |
38 |
> > It would also make "upgrading" to a new release fairly easy, as a |
39 |
> > change in /etc/make.conf from VERSION="2004.0" to VERSION="2004.1" |
40 |
> > would yield the -stable being upgraded to the new release and -updates |
41 |
> > being propagated with the updates. |
42 |
> |
43 |
> It could be that we need to provide some extra upgrade scripts. Maybe we could |
44 |
> at least provide that first of all portage get's updated in such a case. That |
45 |
> would allow us to add the infrastructure if needed. |
46 |
|
47 |
That may very well need to come into being. I understand that there |
48 |
will definitely be some bumps in the road going with this sort of |
49 |
strategy, but I think it lends itself to being the best one for Gentoo |
50 |
in the long run. |
51 |
|
52 |
-- |
53 |
Chris Gianelloni |
54 |
Developer, Gentoo Linux |
55 |
Games Team |
56 |
|
57 |
Is your power animal a pengiun? |