Summary: | =sys-apps/portage-2.2.8-r1: use "=" in output to allow its direct usage by emerge | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Pacho Ramos <pacho> |
Component: | Core - External Interaction | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=618558 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Pacho Ramos
2014-03-02 12:56:36 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. (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. (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. (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. (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 (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. (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 |