There are many situations where it is required that Portage be updated to sucessfully merge a new ebuild, however package maintainers almost NEVER list a particular Portage release as the minimum dependency for their ebuild (and this may be legitamitely difficult keep current and correct). With that said, why not add an optional feature using a setting in make.conf like Auto_Update_Portage=YES that will cause Portage to always look for the most recent stable release of Portage emerge it first and then using the new version of portage re-run the inital command and continue the emerge. I.e. If I type in: emerge --deep -u world then portage will first check for a new version of portage, if there is one it will download it, install it, and then do the "emerge --deep -u world" with the new version. By using a make.conf setting people who don't want that behaviour can turn it off, and it doesn't require always typing a commmand line switch to portage everytime you run it. I have thought about this a bit before, but http://bugs.gentoo.org/show_bug.cgi? id=15229 inspired writing it up. Thanks, Sean
How about doing the update at the end of an rsync instead? Makes a lot more sense to me, as that's when the new portage version becomes available. And possible instead of auto-updating, just giving the user a message that a new portage is available, and they should update before emerging other packages.
I like the rsync idea. That is certainly the appropriate time to do it. I still think it should be able to autoupdate if the user wants it. This makes it easier to keep Portage non-interactive and allow for scripting of some updates.
Done at the end of rsync portage-2.0.47-r1/r2
