| 1 |
On Sun, 20 Sep 2009 13:37:46 +0300 |
| 2 |
Petteri Räty <betelgeuse@g.o> wrote: |
| 3 |
|
| 4 |
> Ryan Hill wrote: |
| 5 |
> > (Yes, this has EAPI in the title, so that means everyone will chime |
| 6 |
> > in) |
| 7 |
> > |
| 8 |
> > I'd like to clarify and (eventually) set in stone our ideas of best |
| 9 |
> > practices when it comes to bumping EAPI for system packages. I was |
| 10 |
> > of the belief that we had decided that system packages should |
| 11 |
> > remain at EAPI 0 for backwards-compatibility reasons. It seems, |
| 12 |
> > however, that this was never written down anywhere and today we |
| 13 |
> > find ourselves in a situation where it is impossible to bootstrap a |
| 14 |
> > Gentoo system from a pre-EAPI-era liveCD due to all python versions |
| 15 |
> > being EAPI 1 or later. Maybe we don't care anymore, but I'd like |
| 16 |
> > to know what people think. |
| 17 |
> > |
| 18 |
> |
| 19 |
> I think the consensus was / is? that the upgrade path from EAPI 0 |
| 20 |
> should have existed until we decide to not support it anymore and the |
| 21 |
> decision should not have been made by for example python maintainers. |
| 22 |
> The only packages that matter are Portage dependencies not the full |
| 23 |
> system target. Basically you need to be able to upgrade your Portage |
| 24 |
> and use the new version. |
| 25 |
|
| 26 |
emerge -1O portage should still work, right? Not that I like python |
| 27 |
being EAPI>0 and that kind of workarounds though... |
| 28 |
|
| 29 |
Alexis. |
Archives