I frequently check "emerge -avu world" and run a mixed x86 and ~x86 system. Given the annoyance of compiling all the time and the instability of some ~x86 packages, it would help to know if I *should* upgrade a package or not. For example, you currently show something like: [ebuild UD] dev-ruby/rails-1.1.6 [1.1.6-r1] USE="fastcgi mysql -doc -postgres -sqlite -sqlite3 (-examples%)" 141 kB and vmware ~ # esearch rails [ Results for search key : rails ] [ Applications found : 1 ] * dev-ruby/rails Latest version available: 1.1.6 Latest version installed: 1.2.0_rc1 Size of downloaded files: 424 kB Homepage: http://www.rubyonrails.org Description: ruby on rails is a web-application and persistance framework License: Ruby I propose two changes: [ebuild UD~] dev-ruby/rails-1.2.0_rc1 [+1.1.6] USE="fastcgi mysql -doc -postgres -sqlite -sqlite3 (-examples%)" 141 kB (where the + is stable, or ~ is testing, etc.) notice how it shows what i have installed is +/~ and also what portage wants to change me to. Both are important pieces of information. and vmware ~ # esearch rails [ Results for search key : rails ] [ Applications found : 1 ] * dev-ruby/rails Latest stable version available: 1.1.6 Latest ~x86 version available: 1.2.0_rc1 Version installed: 1.2.0_rc1 Size of downloaded files: 424 kB Homepage: http://www.rubyonrails.org Description: ruby on rails is a web-application and persistance framework License: Ruby My example may be a bit distorted with actual versions, but I think the idea is sound. Reproducible: Always
Portage can't do such stuff ATM, see the other bug. *** This bug has been marked as a duplicate of bug 1343 ***
I fail to see how this is a duplicate of the other bug. The other one talks about dependencies and such. I'm mearly asking for a bit more information displayed, namely which packages are stable or testing, which surely portage must have access to.
(In reply to comment #2) > I'm mearly asking for a bit more information displayed, namely which packages > are stable or testing, which surely portage must have access to. > Because if portage worked properly, you'd never hit this; it would just stick with one version instead of trying to upgrade and downgrade at the same time. *** This bug has been marked as a duplicate of bug 1343 ***
Perhaps I am being unclear. This is a FEATURE request, not a BUG. Portage is working fine. I have various entries in my /etc/portage/package.mask that are ~x86. When I do an "emerge -avu world" I get a huge list of packages (as expected). All I want to know is, within that list, which packages I have that are installed are stable and which are testing. And which of those package versions 'emerge world' listed are stable or testing. This allows me to make an informed decision if I want to upgrade a certain package or not, or perhaps wait for a stable version (and at that time I can remove the ~x86 package from my /etc/portage/package.mask file for example). But I put the package in my .mask file for a reason at one time. perhaps I needed a feature that wasn't available yet in stable (as it takes forever to become stable it seems) -- but I would PREFER to be running stable packages. This further allows me to run a mix of stable and testing (as I suspect most people do), and have them converge in a controlled mannor as I see fit, as each package version stabalizes with the testing version. In short, all this feature is asking for, is a simple +/~ "flag" next to the two versions shown -- one indicating if the currently installed package is +/~ and the other indicating what the package that portage wants to install is +/~. I didn't think this is so complicated to understand or add. It has NOTHING to do with dependencies. Or a bug or anything else. Just MORE information on the line, just as you indicate versions, use flags, U/D grades, etc... Thank you for re-considering this request. And if it is *I* who misunderstands something that makes this a duplicate, please do explain it to me, because I honestly don't see how they're related.
Last time: this bug is a dupe of Bug 157361 which is a dupe of Bug 1343. There's no point in fixing emerge display for a *bug* in portage. *** This bug has been marked as a duplicate of bug 157361 ***
(In reply to comment #4) Closed, read the other bugs referred to here more carefully.
re-opening due to mis-assignment (and this isn't a duplicate)
re-assign
Thank you for re-opening and re-considering this request. perhaps this will shed more light on a use case (from gentoo-users list): > Anyway, can you explain to me how this feature would help you at all. > I really don't understand the use case for it. Only because you asked... And the short answer is "mostly for stability and book-keeping". I run a mixed environment of stable and testing -- as do most people. Often I run a testing (~x86) package b/c I need a feature that isn't available in the stable version. I would prefer to be all stable, but life is not so kind in the land of Gentoo. And marking packages stable with any regularity seems to be an exercise in patience and nagging and bug requests and waiting and ... So then when I do an "emerge world", there are sometimes hundreds of packages. All nickel and diming me to death. Like a -r1 -r2 -r3... Or a v1.0.1 v1.0.2 etc. All these little incremental ones that are mostly due to them being in testing. I really don't give a rat's ass about them and don't want to spend days compiling things just for one tiny little bug fix, or an ebuild fix or whatever else causes a version bump. Therefore, if I could easily look and see a flag saying, "Hey! This package is now stable and is equal to or newer than the testing version you've got installed". I would be more inclined to upgrade to it, and simultaneously remove the /etc/portage/package.mask entry so I can therefore continue to be stable until the next "must have" feature in some package. That's it. It's quite simple really. I could go on in more depth here, but I feel like I'm just wasting everyone's time. To me, it feels like an obvious and very useful additional information to show, but maybe I'm weird.
(In reply to comment #9) > So then when I do an "emerge world", there are sometimes hundreds of packages. > All nickel and diming me to death. Like a -r1 -r2 -r3... Or a v1.0.1 v1.0.2 > etc. All these little incremental ones that are mostly due to them being in > testing. I really don't give a rat's ass about them and don't want to spend > days compiling things just for one tiny little bug fix, or an ebuild fix or > whatever else causes a version bump. On a sidenode, this is why you shouldn't unmask whole packages but only specific versions. That way you can make sure that portage will only upgrade to higher versions if they are stable. It's also easier to identify stale entries in package.keywords like this: if you see that you have foo-1.6.3 installed and your p.keywords unmasks 1.2.4, things are pretty obvious.
Try using eix. eix uses pretty, colourful formatting which defines which versions of a package are stable, testing or masked etc. Run: echo "app-portage/eix" >> /etc/portage/package.keywords emerge eix && update-eix Example: eix rails In future instead of invoking `emerge --sync` use: eix-sync -v
*** This bug has been marked as a duplicate of bug 168761 ***
