Re: [gentoo-portage-dev] Max parallelization setting
Brian Harring ha scritto:
On Tue, Oct 10, 2006 at 05:27:07PM +0200, Marius Mauch wrote:
On Tue, 10 Oct 2006 00:04:57 -0700
Brian Harring [EMAIL PROTECTED] wrote:
I might be daft (likely), but why not just introduce a var indicating
max parallelization instead? Tweak portage to push that setting into
MAKEOPTS=${MAKEOPTS+${MAKEOPTS} } -j${PARALLELIZATION}.
Might sound daft, but -j is hardcoded parallelization; if you're
trying to run 3 build processes, the original var of -j isn't all
that useful, nor will the hardcoded -j# var set for 3 package build
processes be useful if you're doing a single build.
Depending on number of seperate package build processes possible, the
# of build processes allocated per build process needs to vary
(essentially).
Seems useful as *alternative* to the low level vars, but shouldn't
replace them (so if the low level vars are set they override the global
setting).
Well.. heres the failing.
Say I've got a 32x system; I screw up and have -j32 in my makeopts,
and PARALLELIZATION=32.
Now either the pkg manager needs to understand MAKEOPTS (beyond just
adding a simple string to it), and check for -j*, or it's going to
wind up allowing 32 seperate build jobs, each with -j32.
Personally, I *really* would love to see that loadavg (that would be
one nifty screenshot).
Allowing MAKEOPTS to override the alloted build slices the manager
hands it totally defeats the purpose of moving the parallelization
factor into a seperate var; the intention is to give the manager a
max, and allow it to allocate as it needs depending on the # of build
jobs that can be ran at that point.
Theres no point in doing this if the hole it's trying to plug is
explicitly allowed; at best you wind up with two different vars you
have to keep in sync, at worst, you wind up with the 32*32 exapmle
from above.
Response of course is don't have -j* in your MAKEOPTS; well dar,
thus why allow it? ;)
~harring
Not going deep, sincerly I've read too few form the bug and the thread but:
I'm lucky and I have a cluster of 32 boxes with distcc each with 32
processors.
In such a eco-system the ebuild work is not parallelizable in the
cluster but the compiler work is, those are very different things.
please keep this in account ;)
rgds,
Francesco R.
--
gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Feature request: --history
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I was doing my usual tests the other day when I noticed that I needed history information upon performed emerges, together with what variables were being used and the success state. I know that the log files are there, however I thought that it wouldn't be a bad idea to have an 'emerge --history' command that could show up all this kind of information. I already know that genlop parses the file, but it's missing the USE flags as well. It would be great if at least the header of 'emerge - --info' with gcc version, etc. was shown as well. I would like to know whether you consider that such request is viable or not and if it is worth the effort of being implemented and . Sorry if I missed anything :) - -- Ioannis Aslanidis (deathwing00) Gentoo KDE Herd Member Gentoo Forums Global Moderator GPG Key ID: 0xB9B11F4E GPG Key Fingerprint: 8295 0925 A183 52F2 5A40 4319 CDB9 7DAA B9B1 1F4E http://dev.gentoo.org/~deathwing00 -BEGIN PGP SIGNATURE- iD8DBQFFLNh3zbl9qrmxH04RCh9fAJ9KfNVFu0eKS4uWBG9TG6rX6dGotQCbB0S+ 4nVsGjq33Z01hiIsBq9jqbk= =lJZH -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] GLEP 14?
What's the current status of GLEP 14? This wiki page on glsa-check (which seems to have been more or less unchanged for a very long time) has a roadmap: http://gentoo-wiki.com/Glsa-check The implementation will take place in the following order: 1. distribute GLSAs in the portage tree (completed) 2. release a beta version of the GLSA handling code in gentoolkit (in progress) 3. move dependency handling code from emerge to portage.py 4. add glsa.py to portage 5. integrate functions from glsa-check in emerge and equery Note: This list might be expanded in the future So, is there some work that needs to be done on portage before step 3 happens -- i.e. is now the wrong time to be doing that work? Or is it just lack of somebody to do it? John -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] GLEP 14?
John J Lee wrote: So, is there some work that needs to be done on portage before step 3 happens -- i.e. is now the wrong time to be doing that work? Or is it just lack of somebody to do it? In short: No, yes, yes. What really is needed is sets support in portage. See bug 144480 for that. [1] http://bugs.gentoo.org/show_bug.cgi?id=144480 -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
