Gentoo Archives: gentoo-dev

From: Patrick Lauer <patrick@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo Council Reminder for May 28
Date: Wed, 27 May 2009 21:58:52
Message-Id: 200905272358.44171.patrick@gentoo.org
In Reply to: Re: [gentoo-dev] Gentoo Council Reminder for May 28 by Joe Peterson
1 On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:
2
3 > > Gentoo should not repeat the VHS vs Betamax war. For those who do not
4 > > remember, VHS was the better marketed but inferior technical solution
5 > > that won the standards war for domestic Video recorders.
6 > >
7 > :) Yep. And bad design decisions can haunt is for a long time.
8
9 Actually, once we add the current-glep55 changes we have no way of sanely
10 undoing them if we should realize that they don't work out for us ...
11
12 ... unless we do horrible things like forbidding it, which would cause the
13 same errors we are trying to hide now.
14
15 So unless we have a plan for mid-term future changes I don't see why we would
16 want the current GLEP55 - it's a one-way change in the current state.
17
18
19 > My preference is the one-time .ebuild->.eb change, and putting the EAPI on
20 > the first line, like a #!shebang. Very easy to extract, and good design.
21
22 My preference is freezing the rsync tree, storing all referenced distfiles on
23 at least one mirror, then change the rsync path.
24 That way all "old" users get the last sane upgrade position and all newer
25 changes only hit users that upgraded far enough. Means you can slip in any
26 ebuild format changes without needing to do any changes to the current file
27 and directory layout.
28
29 Do that every EAPI bump and worst case you have 200M per switch on the rsync
30 mirrors and 15G extra storage on a mirror (which is a tolerable expense for
31 infra if it saves us hacking things up backwards to hide errors that shouldn't
32 be there)
33
34 wkr,
35
36 Patrick

Replies

Subject Author
Re: [gentoo-dev] Gentoo Council Reminder for May 28 "Piotr JaroszyƄski" <peper@g.o>