After applying the patch [1] to python-r1, it is possible to change IUSE using a developer-meant environment variable. As stated in bug 447140, it is possible that portage writes the temporary IUSE variable to cache and sticks with that. When that happens, the ebuild dependencies are evaluated with the cached values but the ebuild itself relies on the correct ones. REQUIRED_USE is not evaluated, 'use' conditionals are done on flags-not-in-IUSE (with QA warnings) and empty package is installed successfully. That's quite bad. I think portage should be able to detect that the metadata has changed. In this particular case, it'd be enough if it re-evaluated the metadata when sourcing ebuild to run it, and compared it to the one saved in the cache. If they don't match, portage should delete (or update) the cache entry and abort the merge (or re-enter dependency calc). [1]:http://article.gmane.org/gmane.linux.gentoo.python/289
(In reply to comment #0) > [1]:http://article.gmane.org/gmane.linux.gentoo.python/289 I would suggest to copy the eclass to an overlay and modify it there if you need to. Or if you don't want to do that, then just apply your changes to the eclass in the main tree, and mask the experimental flags if necessary. Note that masked flags do not trigger emerge --newuse or --changed-use, so it won't hurt users in that respect.
(In reply to comment #1) > (In reply to comment #0) > > [1]:http://article.gmane.org/gmane.linux.gentoo.python/289 > > I would suggest to copy the eclass to an overlay and modify it there if you > need to. Or if you don't want to do that, then just apply your changes to > the eclass in the main tree, and mask the experimental flags if necessary. > Note that masked flags do not trigger emerge --newuse or --changed-use, so > it won't hurt users in that respect. It's not about experimental or special flags. It's just switching the supported Python implementations without a need to modify the ebuilds by hand.
