1 |
On Tuesday 03 February 2004 16:28, Chris Gianelloni wrote: |
2 |
> |
3 |
> db-4.1.25_p1-r3 KEYWORDS="ia64 ppc amd64 ppc64 hppa" |
4 |
> db-4.0.14-r2 KEYWORDS="x86 sparc alpha mips" |
5 |
|
6 |
For this ebuild we might look into moving db-4.1 into stable. In any case I |
7 |
seriously doubt whether it is wise for non-experimental architectures to mark |
8 |
ebuilds stable that are not stable for the main arch (x86) (experimental |
9 |
being the amd64 and ia64 archs) |
10 |
|
11 |
> Now, depending on which arch you'r eon would entirely depend on which |
12 |
> version you get. |
13 |
> |
14 |
> There should be ZERO updates in the actual stable tree. You should be |
15 |
> able to install a machine on day 1 of the release, or day 89 and still |
16 |
> get the EXACT same tree, otherwise, it isn't stable. |
17 |
|
18 |
Actually I would like to be able to download the tree 10 years from now and |
19 |
given that the source files are there it should be possible to build a gentoo |
20 |
system (NOT SECURE, not all hardware) that is the same to one from now. |
21 |
|
22 |
> |
23 |
> Updates would have to be provided separately, though still via rsync. |
24 |
> I would see something like /usr/portage-stable and |
25 |
> /usr/portage-updates, with -stable being static with the release used |
26 |
> and -updates being all the changes since release. |
27 |
> |
28 |
> It would also make "upgrading" to a new release fairly easy, as a |
29 |
> change in /etc/make.conf from VERSION="2004.0" to VERSION="2004.1" |
30 |
> would yield the -stable being upgraded to the new release and -updates |
31 |
> being propagated with the updates. |
32 |
|
33 |
It could be that we need to provide some extra upgrade scripts. Maybe we could |
34 |
at least provide that first of all portage get's updated in such a case. That |
35 |
would allow us to add the infrastructure if needed. |
36 |
|
37 |
Paul |
38 |
|
39 |
-- |
40 |
Paul de Vrieze |
41 |
Researcher |
42 |
Mail: pauldv@××××××.nl |
43 |
Homepage: http://www.cs.kun.nl/~pauldv |