Re: [gentoo-user] Can someone please explain to me why these bugs are duplicates?
Daniel Iliev wrote: As already mentioned in this thread the workaround is to un-keyword a concrete version, not the whole package. This is not a workaround, it's a _better way of achieving the goal. When portage just flags packages gone stable, you have to watch the pretend output yourself for these flags. When using = or ~ you can just forget about the package, portage will automatically handle an upgrade to the next stable version. Benno -- gentoo-user@gentoo.org mailing list
[gentoo-user] Can someone please explain to me why these bugs are duplicates?
Honestly, I really don't see how they're even remotely related. So either I'm just dense, or the maintainer is not understanding my request... It's extremely frustrating. [Bug 165709] When viewing emerge -avu world show which packages are stable (or ~x86) http://bugs.gentoo.org/show_bug.cgi?id=165709 is my original one http://bugs.gentoo.org/show_bug.cgi?id=157361 is what they claim is a duplicate And http://bugs.gentoo.org/show_bug.cgi?id=1343 DÆVID -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can someone please explain to me why these bugs are duplicates?
Daevid Vincent wrote: Honestly, I really don't see how they're even remotely related. So either I'm just dense, or the maintainer is not understanding my request... It's extremely frustrating. Yes, the bug wrangler looks a bit overworked sometimes. :| Those bugs don't seem duplicates to me either. But what you're asking is simple: in your .unmask and .keywords files don't unmask a package name but a specific package version (use the = or ~ operators). Then you'll only be using that specific unstable version, and go back to using stable versions when they become available. Benno -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can someone please explain to me why these bugs are duplicates?
On Wednesday 07 February 2007 23:19:53 Daevid Vincent wrote: Honestly, I really don't see how they're even remotely related. So either I'm just dense, or the maintainer is not understanding my request... It's extremely frustrating. [Bug 165709] When viewing emerge -avu world show which packages are stable (or ~x86) http://bugs.gentoo.org/show_bug.cgi?id=165709 is my original one http://bugs.gentoo.org/show_bug.cgi?id=157361 is what they claim is a duplicate And http://bugs.gentoo.org/show_bug.cgi?id=1343 Bug #157361 clearly is a dupe of bug #1343. There's no question about that. If you upgrade to Portage 2.1.2 (which will go stable soon) you'll find that it will detect that two versions of mozilla-firefox within the same slot (firefox only has one slot) are being pulled in and hence it will die up front while telling you about the problem. It still won't be able to solve it without your help though. So... it will be a lot easier for me to tell you what your options are wrt. working around this bug if you post the output of: # emerge -Dup world --tree --verbose Wrt. bug #165709 I'd probably have pointed you towards app-portage/eix and resolved it as WONTFIX or even INVALID as I really don't see the point in that feature request. There are a lot of tools including eix that are a lot more suitable for queries about what is stable and what isn't. I do understand jakubs reasoning for thinking it's triggered by bug #157361 and hence marking it a dupe of that though. I think reopening the same bug 3 times is a terrible idea. It clearly doesn't help anyone. The most obvious options after the first time are to CC the [EMAIL PROTECTED] alias on the bug to make the portage devs aware of it (while commenting about why you do that), or to post a mail here, on the gentoo-dev-portage@ mailing list (this is a feature request for portage after all) or log onto irc and talk to the portage devs in #gentoo-portage on freenode. -- Bo Andresen pgp0G8aJCzB9v.pgp Description: PGP signature
RE: [gentoo-user] Can someone please explain to me why these bugs are duplicates?
On Wednesday 07 February 2007 23:19:53 Daevid Vincent wrote: Honestly, I really don't see how they're even remotely related. So either I'm just dense, or the maintainer is not understanding my request... It's extremely frustrating. [Bug 165709] When viewing emerge -avu world show which packages are stable (or ~x86) http://bugs.gentoo.org/show_bug.cgi?id=165709 is my original one So... it will be a lot easier for me to tell you what your options are wrt. working around this bug if you post the output of: # emerge -Dup world --tree --verbose Thanks, but I don't have a bug to solve here. Just the feature request. Wrt. bug #165709 I'd probably have pointed you towards app-portage/eix and resolved it as WONTFIX or even INVALID as I really don't see the point in that feature request. There are a lot of tools including eix that are a lot more suitable for queries about what is stable and what isn't. I do understand jakubs reasoning for thinking it's triggered by bug #157361 and hence marking it a dupe of that though. Yes, but then I have to manually, one at a time search eix and compare to the output of 'emerge world'. I use eix. That's actually why I suspect that the feature could be implemented fairly easily. Portage has all the info it needs. I think reopening the same bug 3 times is a terrible idea. It clearly doesn't help anyone. Nor does just blindly closing it without really comprehending what the request is for. The most obvious options after the first time are to CC the [EMAIL PROTECTED] alias on the bug to make the portage devs aware of it (while commenting about why you do that), or to post a mail here, on the gentoo-dev-portage@ mailing list (this is a feature request for portage after all) or log onto irc and talk to the portage devs in #gentoo-portage on freenode. Actually, I'll just concede defeat. :( Obviously the maintainer has either a closed mind and is unwilling to consider my request, or he just doesn't get it and wants to lump two disjointed bugs together. I get the feeling that even after all the work to get it into an official bug/request. I'll either be greeted with learn python and code it yourself as a patch, or it will sit there forever amongst the thousands of other bugs... Mostly by posting here, I just wanted to know if I was missing something obvious and being a retard or if the maintainer was... *sigh* ...also that maybe someone else would say, oh yeah, I like that idea and perhaps could articulate it better than I... DÆVID -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can someone please explain to me why these bugs are duplicates?
On Thursday 08 February 2007 00:59:49 Daevid Vincent wrote: So... it will be a lot easier for me to tell you what your options are wrt. working around this bug if you post the output of: # emerge -Dup world --tree --verbose Thanks, but I don't have a bug to solve here. Just the feature request. It would make it easier to explain why bug #157361 is a dupe of #1343 though. Assuming that still isn't clear to you? Wrt. bug #165709 I'd probably have pointed you towards app-portage/eix and resolved it as WONTFIX or even INVALID as I really don't see the point in that feature request. There are a lot of tools including eix that are a lot more suitable for queries about what is stable and what isn't. I do understand jakubs reasoning for thinking it's triggered by bug #157361 and hence marking it a dupe of that though. Yes, but then I have to manually, one at a time search eix and compare to the output of 'emerge world'. I use eix. That's actually why I suspect that the feature could be implemented fairly easily. Portage has all the info it needs. You do know that eix is not related to portage in any way? Anyway, can you explain to me how this feature would help you at all. I really don't understand the use case for it. I think reopening the same bug 3 times is a terrible idea. It clearly doesn't help anyone. Nor does just blindly closing it without really comprehending what the request is for. Jakub is handling a lot of bugs so obviously he does make mistakes occasionally. I don't think he makes that many of them but arguably he should have reassigned #165709 to dev-portage@ and let them handle it. Do note that Jakub is a bug-wrangler not a maintainer. The most obvious options after the first time are to CC the [EMAIL PROTECTED] alias on the bug to make the portage devs aware of it (while commenting about why you do that), [...]. [SNIP] Actually, I'll just concede defeat. :( That's your decision then. -- Bo Andresen pgpTjSEr9HKpr.pgp Description: PGP signature
RE: [gentoo-user] Can someone please explain to me why these bugs are duplicates?
Yes, but then I have to manually, one at a time search eix and compare to the output of 'emerge world'. I use eix. That's actually why I suspect that the feature could be implemented fairly easily. Portage has all the info it needs. You do know that eix is not related to portage in any way? Not to argue semantics, but I'm guessing, and I could be wrong, but 'esearch' or whatever other database (used generically) that portage uses has at least what versions there are of each package and if they're ~x86 or not. That's all that's required for this request. 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. ÐÆ5ÏÐ Some people, when confronted with a problem, think 'I know, I'll use XML.' Now they have two problems. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Can someone please explain to me why these bugs are duplicates?
On Thursday 08 February 2007 02:13:10 Daevid Vincent wrote: 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 [...] [SNIP] Hmm.. I guess that does make sense then. As you've noticed it's been reassigned now so the devs who would be doing the work can decide if they'll do anything about it... If anything like this happens again just CC them on the bug. -- Bo Andresen pgpx4bCVF3U15.pgp Description: PGP signature
Re: [gentoo-user] Can someone please explain to me why these bugs are duplicates?
This makes (at least) two of us (me and the OP) who don't understand the relation between the request for indication if portage wants to install a stable or testing package and the bug where in some cases portage misses that some dependencies are already provided. The feature the OP requests would be helpful in a situation like this: The user wants a stable system. The user wants a package with features available only in the testing/masked ...newer version. In order to get those features the user un-keywords the package in question. After some time portage wants to upgrade that package. Now. The user doesn't want to upgrade the testing version with another testing version but prefers to revert back to a stable version providing the features (s)he needs. Here would come the use of this feature which would indicate what kind of package (stable or not) portage wants to install as an upgrade. As already mentioned in this thread the workaround is to un-keyword a concrete version, not the whole package. Btw the bug is reopened by another developer who also thinks it is not a duplicate. Lets see if such a feature would appear after some time. ;-) -- Best regards, Daniel -- gentoo-user@gentoo.org mailing list
