Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 503204 - =sys-apps/portage-2.2.8-r1: use "=" in output to allow its direct usage by emerge
Summary: =sys-apps/portage-2.2.8-r1: use "=" in output to allow its direct usage by em...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - External Interaction (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-02 12:56 UTC by Pacho Ramos
Modified: 2017-05-15 19:05 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pacho Ramos gentoo-dev 2014-03-02 12:56:36 UTC
Currently we sometimes get outputs from portage like:
 * Error: circular dependencies:

(dev-java/junit-4.11::gentoo, ebuild scheduled for merge) depends on
 (dev-java/hamcrest-core-1.3::gentoo, ebuild scheduled for merge) (buildtime)
  (dev-java/hamcrest-generator-1.3-r1::gentoo, ebuild scheduled for merge) (buildtime)
   (dev-java/qdox-1.12-r1::gentoo, ebuild scheduled for merge) (buildtime)
    (dev-java/jmock-1.1.0-r2::gentoo, ebuild scheduled for merge) (buildtime)
     (dev-java/ant-junit-1.9.2::gentoo, ebuild scheduled for merge) (buildtime)
      (dev-java/junit-4.11::gentoo, ebuild scheduled for merge) (buildtime)

It might be possible to break this cycle
by applying the following change:
- dev-java/jmock-1.1.0-r2 (Change USE: -test)

Note that this change can be reverted, once the package has been installed.

Note that the dependency graph contains a lot of cycles.
Several changes might be required to resolve all cycles.
Temporarily changing some use flag for all packages might be the better option.

Why not tend to use "=${CATEGORY}/${P}" when possible to not need to play with "=" manually when copy&pasting and using the output in scripts?

(As a side not I am thinking that maybe would be interesting to add a way for portage to automatically switch "-test" as it suggests to not need me to re-run it tons of times :S)

Thanks!
Comment 1 Sebastian Luther (few) 2014-03-02 18:32:30 UTC
(In reply to Pacho Ramos from comment #0)
 
> It might be possible to break this cycle
> by applying the following change:
> - dev-java/jmock-1.1.0-r2 (Change USE: -test)
> [...]
> 
> Why not tend to use "=${CATEGORY}/${P}" when possible to not need to play
> with "=" manually when copy&pasting and using the output in scripts?

I wonder if this shouldn't look like the --autounmask output.

> 
> (As a side not I am thinking that maybe would be interesting to add a way
> for portage to automatically switch "-test" as it suggests to not need me to
> re-run it tons of times :S)
> 
> Thanks!

Adding support for on-the-fly use flag changing would require a huge amount of work.
Comment 2 Pacho Ramos gentoo-dev 2014-03-02 21:49:12 UTC
(In reply to Sebastian Luther (few) from comment #1)
[...]
> > (As a side not I am thinking that maybe would be interesting to add a way
> > for portage to automatically switch "-test" as it suggests to not need me to
> > re-run it tons of times :S)
> > 
> > Thanks!
> 
> Adding support for on-the-fly use flag changing would require a huge amount
> of work.

The idea was about adding it only for the cases, like this one, where portage is already able to suggest that disabling the flag could work. As it's already suggesting the user to manually do that, the idea would be to add an option to tell portage to directly try that when this kind of conflict is get.
Comment 3 Alec Warner (RETIRED) archtester gentoo-dev Security 2014-03-02 22:30:26 UTC
(In reply to Sebastian Luther (few) from comment #1)
> (In reply to Pacho Ramos from comment #0)
>  
> > It might be possible to break this cycle
> > by applying the following change:
> > - dev-java/jmock-1.1.0-r2 (Change USE: -test)
> > [...]
> > 
> > Why not tend to use "=${CATEGORY}/${P}" when possible to not need to play
> > with "=" manually when copy&pasting and using the output in scripts?
> 
> I wonder if this shouldn't look like the --autounmask output.

If we already have atom objects (instead of just a string) it seems like it should have a sensible rendering function, eg: Atom("dev-java/jmock-1.1.0-r2).Render() returns "=dev-java/jmock-1.1.0-r2"

Not sure how plausible it is to make this str() (as it might screw up ordering or other stuff?)

-A

> 
> > 
> > (As a side not I am thinking that maybe would be interesting to add a way
> > for portage to automatically switch "-test" as it suggests to not need me to
> > re-run it tons of times :S)
> > 
> > Thanks!
> 
> Adding support for on-the-fly use flag changing would require a huge amount
> of work.
Comment 4 Sebastian Luther (few) 2014-03-03 16:36:12 UTC
(In reply to Alec Warner from comment #3)
> If we already have atom objects (instead of just a string) it seems like it
> should have a sensible rendering function, eg:
> Atom("dev-java/jmock-1.1.0-r2).Render() returns "=dev-java/jmock-1.1.0-r2"

The output mentioned above doesn't come from the Atom class. The Atom class is already fine.

The output comes from _emerge.Package.__str__. Nothing in emerge would break if we'd change that.
Comment 5 Alec Warner (RETIRED) archtester gentoo-dev Security 2014-03-03 17:22:58 UTC
(In reply to Sebastian Luther (few) from comment #4)
> (In reply to Alec Warner from comment #3)
> > If we already have atom objects (instead of just a string) it seems like it
> > should have a sensible rendering function, eg:
> > Atom("dev-java/jmock-1.1.0-r2).Render() returns "=dev-java/jmock-1.1.0-r2"
> 
> The output mentioned above doesn't come from the Atom class. The Atom class
> is already fine.
> 
> The output comes from _emerge.Package.__str__. Nothing in emerge would break
> if we'd change that.

Right, all I'm saying is that we should have rendering code in one place is all ;)

-A
Comment 6 Sebastian Luther (few) 2014-03-03 17:35:24 UTC
(In reply to Alec Warner from comment #5)
> Right, all I'm saying is that we should have rendering code in one place is
> all ;)
> 
This distinction between Atom and Package can't be removed. Package.__str__ for example depends on the merge type (ebuild, binary, installed), a concept not know for the Atom class. 
On the other hand, a package always has a version, slot, sub_slot, repo,... An Atom doesn't have to. But it could have a version range, a concept which doesn't make sense for a Package.
Comment 7 Alec Warner (RETIRED) archtester gentoo-dev Security 2014-03-03 18:26:01 UTC
(In reply to Sebastian Luther (few) from comment #6)
> (In reply to Alec Warner from comment #5)
> > Right, all I'm saying is that we should have rendering code in one place is
> > all ;)
> > 
> This distinction between Atom and Package can't be removed. Package.__str__
> for example depends on the merge type (ebuild, binary, installed), a concept
> not know for the Atom class.
> On the other hand, a package always has a version, slot, sub_slot, repo,...
> An Atom doesn't have to. But it could have a version range, a concept which
> doesn't make sense for a Package.

So we are fixing Package? :)

-A