On Wed, Oct 29, 2008 at 7:26 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
> I don't like package managers which require interactivity.
> emerge -uvDp world | less is easier to parse then emerge -upDa world.
> Why? Because I don't have to find a way of transferring <return> if
> less handles all of the keyboard input.
> So I prefer two stages:
> 1) pretend merge - single verbosity - and look at output
> 2) actual merge - normal / quiet - and pipe to tee

So what you're saying... is that emerge should have a switch to turn
on, when using -p, -a, and/or -t, a pager? Particularly one that,
until you're content with -a in particular, doesn't accidentally have
a means of handing output back off to the emerge for the yes/no? This
would spare the double run of the dependency checker while giving
users who want it a pager to use and giving the rest the same
functionality a simple -a gives now... something like etc-update's use
of a pager comes to mind. Let's see... -P is taken for --prune ...
--less/-L or... --more/-m ... --more/-M ? Of course, --pager/-M would
work too, but it's less intuitive (we already have --unmerge/-C ... so
why not, I suppose). Not *quite* sure I'm up to the task at the
moment, though.

--
Poison [BLX]
Joshua M. Murphy

On Wed, Oct 29, 2008 at 9:44 PM, Joshua Murphy <poisonbl@gmail.com> wrote:
> On Wed, Oct 29, 2008 at 7:26 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
>> I don't like package managers which require interactivity.
>> emerge -uvDp world | less is easier to parse then emerge -upDa world.
>> Why? Because I don't have to find a way of transferring <return> if
>> less handles all of the keyboard input.
>> So I prefer two stages:
>> 1) pretend merge - single verbosity - and look at output
>> 2) actual merge - normal / quiet - and pipe to tee
>
> So what you're saying... is that emerge should have a switch to turn
> on, when using -p, -a, and/or -t, a pager? Particularly one that,
> until you're content with -a in particular, doesn't accidentally have
> a means of handing output back off to the emerge for the yes/no? This
Yes.
> would spare the double run of the dependency checker while giving
> users who want it a pager to use and giving the rest the same
> functionality a simple -a gives now... something like etc-update's use
> of a pager comes to mind. Let's see... -P is taken for --prune ...
> --less/-L or... --more/-m ... --more/-M ? Of course, --pager/-M would
> work too, but it's less intuitive (we already have --unmerge/-C ... so
> why not, I suppose). Not *quite* sure I'm up to the task at the
> moment, though.

But I usually use emerge -p > file in order to see the difference in
dependencies from testing USE flags.
I would always choose -pN over -aN.

Where's the portage to-do list?
If you can find it, add these two items:
fix the uname
add pager support for -p, -a, -t



--
Andrey Vul

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

On Wednesday 29 October 2008 19:59:11 Alan McKinnon wrote:

> A last note on emerge's output, especially with blockers: the time spent
> to read all the portage pages (several times) is time very well spent. I
> recommend when next you get blockers, is to rerun emerge with -t and take
> note of what packages cause a blocker to be pulled in or up|downgraded.
> make a list of everything involved and read the ebuilds. Plot it all out
> with pen and pencil, do this repetitively till you have a lightbulb
> moment where it all suddenly makes sense.

Sound advice, but it didn't help me last week. I had to take a more devious
approach involving a new test system and repeated attempts to install the
same packages on it as were on the live system until I found the one that
was causing the trouble. It was then a simple matter to remove it from the
world file, where it shouldn't have been in the first place, and I can now
dispense with the test system.

So I could have saved myself several days of head-banging if I'd just looked
in the world file - I'd have noticed the offender straight away. 20-20
hindsight. Wonderful.

> Most folks around here have done this at some point and there doesn't
> seem to be a shortcut :-)

Indeed.

--
Rgds
Peter

On Wed, Oct 29, 2008 at 10:23 PM, Andrey Vul <andrey.vul@gmail.com> wrote:
> But I usually use emerge -p > file in order to see the difference in
> dependencies from testing USE flags.
> I would always choose -pN over -aN.
>
> Where's the portage to-do list?
> If you can find it, add these two items:
> fix the uname
> add pager support for -p, -a, -t

Well, I didn't find it with the miserably little effort I put into
looking... so instead, I wrote up a quick hack to emerge to implement
use of a pager any time the internal display() function is called. I
made the mistake of writing it against the 'stable' version of
portage, though... so I'll be (hopefully) porting it over to Portage
2.2_rc12 (the newest my current state of laziness allows on my amd64
machine). Any chance anyone here's a bit more skilled with python than
I am and would want to remind me of all the error checking I left out?
After I get a patch handy, at least...

As for the 'fix the uname' bit... I haven't had a chance to dig
through the changelogs to see the who/when/why of the change that made
it what it is now, and whether (as was clarified as likely in the
related thread here) the current output is what's "intended."

--
Poison [BLX]
Joshua M. Murphy