| Summary: | =sys-apps/portage-2.2.1 stable request | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
| Component: | [OLD] Keywording and Stabilization | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | boxcars, dwfreed, rdalek1967 |
| Priority: | Normal | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 478320, 479062, 482942 | ||
| Bug Blocks: | 472632, 478252 | ||
|
Description
Pacho Ramos
2013-07-30 20:13:27 UTC
From a tools-portage perspective, we have to fix/stablize the tools to work with this version of portage and the repos.conf changes. The tools-portage team is low on resources to do this quickly right now, so any and all help is appreciated. (In reply to Paul Varner from comment #1) > From a tools-portage perspective, we have to fix/stablize the tools to work > with this version of portage and the repos.conf changes. I've updated the ebuilds to automatically generate a make.conf PORTDIR="/usr/portage" backward compatibility setting. It shows like a normal CONFIG_PROTECT update that the user will be able to apply via etc-update or dispatch-conf. Also, see bug 479062 for catalyst make.conf patch. I see portage-2.1.13.2 is removed from the tree. Is the plan now to stabilize 2.2.0 without any more 2.1.x stabilizations? (In reply to boxcars from comment #4) > I see portage-2.1.13.2 is removed from the tree. Is the plan now to > stabilize 2.2.0 without any more 2.1.x stabilizations? Yes, well actually I want to do a 2.2.1 release and stabilize that, because of bug 481628. Actually, bug 481628 was not really a regression, so we're not waiting on that. However bug 480736 is a regression, and it's now fixed in 2.2.1. @arch teams: Please stabilize sys-apps/portage-2.2.1, but first stabilize app-portage/eix-0.29.3 if you haven't already (bug 482942). Bug #472632 tracks bugs fixed since 2.1.12.2. It's possible that some users will experience some minor snags involving the new userpriv (bug 477664) and usersync (bug 477682) FEATURES defaults, but the upgrade should be smooth for most users. If you don't have userpriv enabled yet, and you have lots of "live" sources in $DISTDIR, then pkg_postinst may consume a lot of time adjusting ownership of files in $DISTDIR. Stable for HPPA. x86 stable arm stable Before try to keyword I update the entire gentoo-x86 and I get: sys-apps/portage/portage-2.2.1.ebuild: DEPEND: amd64(default/linux/amd64/13.0) ['virtual/pypy:1.9', 'dev-lang/python:3.1'] (In reply to Agostino Sarubbo from comment #11) > Before try to keyword I update the entire gentoo-x86 and I get: > > sys-apps/portage/portage-2.2.1.ebuild: DEPEND: > amd64(default/linux/amd64/13.0) ['virtual/pypy:1.9', 'dev-lang/python:3.1'] I've committed a fix for this. Though, as long as portage is going to inline parts of the eclasses, issues like this are going to arise every time we change the list of supported implementations, and possibly other internals. amd64 stable ppc64 stable ia64 stable alpha stable sparc stable ppc stable SH is not anymore a stable arch, removing it from the cc list S390 is not anymore a stable arch, removing it from the cc list M68K is not anymore a stable arch, removing it from the cc list |
