I'd like to be able to say: % emerge -upv world --threshold=revision This would show me all possible updates. % emerge -upv world --threshold=release This would show me all possible updates whose version (not revision number) is newer than my installed version. % emerge -upv world --threshold=major This would show me all possible updates whose major version number, like the 1 in 1.2.3, is newer than the major version number of my latest installed version. I want this because when I emerge -upv world, I see about 80 updates that I don't care about because they're only newer revisions, and when I check the changelog, it's usually something like "added x86 to stable," so it's not like I *should* be rebuilding it.
Not saying that this functionality isn't useful anyway, but a revision should only occur when there is a bugfix of some sort. Adding an architecture or changing the keywords for an architecture should not cause a revision bump.
I agree. I think there should be two kinds of revisions, rebuild-worthy revisions and non-rebuilding revisions. Maybe it could be something like package-1.2-r2c, where the rebuilding revision is 2, and the non-rebuilding revision is 3 (c = 3). There also needs to be a means of describing changes between versions easily and probably from within emerge -u. But until those things are implemented, I think this new emerge option is a good solution.
*** Bug 39501 has been marked as a duplicate of this bug. ***
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
Reopening for consideration. I know that quite a few people want such a feature, but I don't like it.
ciap ciao
test
Closing per comment #5.
