Handling the gobs of info output by emerge --regen

[eatnumber1]

So, I have my emerge configured to do a --regen after every sync... I find it annoying however that --regen outputs tons of information to the screen. So I wrote a little bash script to hide that info, and give a little progress info.

Code: Select all

#!/bin/bash
function wc_l {
	local count
	declare -i count=0
	while read line; do
		count+=1
	done
	echo $count
}

echo -n "Computing the number of packages in portage... "
declare -i PACKAGES=$(eix --nocolor --compact --pure-packages --only-names | wc_l)
echo "$PACKAGES"

declare -i count=0
function count_f {
	printf '\rRegenerating Porage Cache: %5i/%i' $count $PACKAGES
	count+=1
}
count_f

emerge --regen | \
while read line; do
	[[ "$line" =~ ^Processing\ .*/.* ]] && count_f
done
echo

This is what an example run looks like:

Code: Select all

Computing the number of packages in portage... 14724
Regenerating Porage Cache:  1942/14724

Note: This script requires eix to be installed.

If anyone knows a better/faster/alternative way of counting the number of packages in portage + in overlays, I'd very much like to know.

[Sadako]

I'm doing something similar, ie have a wrapper script around emerge --sync followed by --regen, but I simply append --quiet to the emerge --regen command.

What part appears to be slow, ie what do you hope to speed up?

The only thing I think you could get rid of is the `declare -i PACKAGES=$(eix -cn* | wc_l)`, you could try something like this instead;

Code: Select all

declare -i PACKAGES=0
for FOO in /usr/portage/*-*/*; do
    [ -d "${FOO}" ] && PACKAGES+=1
done

Rather hackish, and I can't even guarantee it'll return the correct number of packages, but you can test it against what eix reports (and don't have eix installed...).

In what I have above, you could replace '[ -d "${FOO}" ] &&' with '[ "${FOO##*/}" = 'metadata.xml' ] ||', which may be a little faster, but the former just seems more "proper".

You'll need to add such a for loop for each overlay, however are you sure `emerge --regen` does any such processing of overlays?

[eatnumber1]

I'm doing something similar, ie have a wrapper script around emerge --sync followed by --regen, but I simply append --quiet to the emerge --regen command.

What part appears to be slow, ie what do you hope to speed up?

The only thing I think you could get rid of is the `declare -i PACKAGES=$(eix -cn* | wc_l)`, you could try something like this instead;

Code: Select all

declare -i PACKAGES=0
for FOO in /usr/portage/*-*/*; do
    [ -d "${FOO}" ] && PACKAGES+=1
done

Rather hackish, and I can't even guarantee it'll return the correct number of packages, but you can test it against what eix reports (and don't have eix installed...).

In what I have above, you could replace '[ -d "${FOO}" ] &&' with '[ "${FOO##*/}" = 'metadata.xml' ] ||', which may be a little faster, but the former just seems more "proper".

You'll need to add such a for loop for each overlay, however are you sure `emerge --regen` does any such processing of overlays?

Yeah, i'm sure --regen does processing of overlays.

Your method unfortunately won't work because overlays add ebuilds for packages already in portage... your method would count those twice.

And yeah... the eix command is what I was hoping to get rid of.

[Sadako]

Okay, you're right about --regen and overlays, just checked the mod times of the files in /var/cache/edb/dep/var/portage/overlay/.

The following will take care of overlays, and remove dupes, but it's fugly;

Code: Select all

find /usr/portage/ /var/portage/overlay/ -maxdepth 2 -type d -wholename *-*/* | sed -e 's:/usr/portage/::' -e 's:/var/portage/overlay/::' | sort | uniq | wc -l

Also, you'll need to add each overlay yourself, although I'm sure that can be worked around (I only have the one overlay myself).

One problem with it, though; it doesn't count "virtual" ebuilds, but that could be worked around easily.

All very ugly, I'm sure there's a better way.

Roughly how long or slow is the eix command?

[eatnumber1]

Also, I hadn't thought of --quiet... but I like my solution better because it allows for displaying some progress to what is a very long operation.