On Thursday 28 May 2009 00:12:56 Piotr Jaroszyński wrote:
> 2009/5/27 Patrick Lauer <patr...@gentoo.org>:
> > On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:
> >> > Gentoo should not repeat the VHS vs Betamax war. For those who do not
> >> > remember, VHS was the better marketed but inferior technical solution
> >> > that won the standards war for domestic Video recorders.
> >> >
> >> :)  Yep.  And bad design decisions can haunt is for a long time.
> >
> > Actually, once we add the current-glep55 changes we have no way of sanely
> > undoing them if we should realize that they don't work out for us ...
> >
> > ... unless we do horrible things like forbidding it, which would cause
> > the same errors we are trying to hide now.
> >
> > So unless we have a plan for mid-term future changes I don't see why we
> > would want the current GLEP55 - it's a one-way change in the current
> > state.
>
> How is it one-way exactly? You can do pretty much anything you want in
> a new EAPI (that's the point).

You cannot undo it.

In other words, you'll have to allow stupid filenames until the end of times 
even if you are quite positively sure that it is, right now, a bad idea.
>
> >> My preference is the one-time .ebuild->.eb change, and putting the EAPI
> >> on the first line, like a #!shebang.  Very easy to extract, and good
> >> design.
> >
> > My preference is freezing the rsync tree, storing all referenced
> > distfiles on at least one mirror, then change the rsync path.
> > That way all "old" users get the last sane upgrade position (...)
>
> And bugs and security vulnerabilities too. Or do you propose
> maintaining multiple trees at the same time? I think one of the main
> points of EAPI was to avoid doing exactly that.

Not at all. Just an upgrade snapshot so you can get "old" users into a known 
state, then let them upgrade at least the package manager to a point where 
they can use the rest. That snapshot should be seen as a transient helper, not 
as a "release" ...

Reply via email to