[gentoo-user] Can someone please explain to me why these bugs are duplicates?

[gentoo-user] Can someone please explain to me why these bugs are duplicates?

[Daevid Vincent]

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?

[Benno Schulenberg]

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?

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

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 
dev-portage@gentoo.org 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-user] Can someone please explain to me why these bugs are duplicates?

[Daevid Vincent]

> 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 
> dev-portage@gentoo.org 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?

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

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
> > dev-portage@gentoo.org 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [gentoo-user] Can someone please explain to me why these bugs are duplicates?

[Daevid Vincent]

> > 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?

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Can someone please explain to me why these bugs are duplicates?

[Daniel Iliev]

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

[gentoo-user] Re: Can someone please explain to me why these bugs are duplicates?

[Harm Geerts]

On Thursday 08 February 2007, Daevid Vincent wrote:
> 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.

Instead of keywording a package you should keyword a specific version 
(including a revision if you will)
This way there will be no upgrades unless that package goes stable.

The tools are there, you just haven't used them correctly :)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Can someone please explain to me why these bugs are duplicates?

[Benno Schulenberg]

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