Zack Medico - Latest comments

In response to: New overlay config files: metadata/layout.conf and /etc/portage/repos.conf

Markos Chandras [Visitor] — Tue, 21 Apr 2009 21:33:08 +0000

Interesting approach :)
It is a smart way to protect users against unwanted overrides, which leads to increased QA.

Good job :)

In response to: Informative output for unresolved blockers

David Abbott [Visitor] — Sat, 07 Feb 2009 02:41:58 +0000

Thank you for all your excellent work, very much appreciated by all your loyal fans, the Gentoo users.

In response to: Informative output for unresolved blockers

Fitzcarraldo [Visitor] — Fri, 06 Feb 2009 09:36:20 +0000

Great stuff. And asking the user if (s)he would like an obsolete package removed from the world file would be excellent.

In response to: Portage now supports building multiple packages in parallel

Zac MEDICO [Member] — Thu, 14 Aug 2008 05:30:37 +0000

We might consider implementing more aggressive parallelization algorithms in the future.

Now I've found a way to make the parallelization algorithm more aggressive in some cases, without making the build order any less optimal. The patch is in svn r11405 and it will be included in >=sys-apps/portage-2.2_rc9.

In response to: Portage now supports building multiple packages in parallel

Zac MEDICO [Member] — Wed, 06 Aug 2008 22:32:19 +0000

a) after --resume, and
b) even after --keep-going resumes
since I do not see any parallel emerges anymore. :-(

In fact, IIRC after --resume the compressed output of parallel emerges would not even appear, so the new options probably did not survive the restart.

I can confirm that --resume does not properly preserve --jobs and --load-average options, so I will have that fixed in the next release (that will be 2.2_rc7).

I suspect that the --keep-going behavior that you've observed is due to the topology of the dependency graph, and the following algorithm:

The algorithm used to choose packages that will execute concurrently with other packages is as conservative as possible in the sense that a given package will not be executed if the subgraph composed of its direct and indirect dependencies contains any scheduled merges. By ensuring that the subgraph of deep dependencies is fully up to date in this way, potential problems are avoided which could be triggered by other build orders that are less optimal.

We might consider implementing more aggressive parallelization algorithms in the future. However, those who would consider choosing a more aggressive algorithm should ask themselves why they are in such a hurry. A more aggressive algorithm is inherently less optimal and therefore it only makes sense when there is some kind of deadline to meet. Even with a deadline, there are other techniques such as ccache and distcc which can help improve performance without sacrificing optimal build order.

In response to: Portage now supports building multiple packages in parallel

Hans Meine [Visitor] — Wed, 06 Aug 2008 13:06:36 +0000

I have been using these great new features on a multi-core machine during the last days, but it seems that portage has problems
a) after --resume, and
b) even after --keep-going resumes
since I do not see any parallel emerges anymore. :-(

In fact, IIRC after --resume the compressed output of parallel emerges would not even appear, so the new options probably did not survive the restart.

But it's a great feature; in the past I have always tried to mimic that manually, but that would be a lot of work, far from perfect, and sometimes compile some common dependencies more than once if not done carefully.

Thus, I am looking forward to see this feature become more mature.

In response to: New @live-rebuild and @module-rebuild package sets

Zac MEDICO [Member] — Sat, 02 Aug 2008 02:08:15 +0000

Should note that @live-rebuild may catch packages that inherit those eclasses, but aren't really "live" packages

It might be good to add support for RESTRICT=live (with the reverse meaning of what was originally suggested in bug 233589) since it will also be useful for repoman's LIVEVCS.stable check. I've just sent an RFC email to the gentoo-dev mailing list.

In response to: New @live-rebuild and @module-rebuild package sets

Zac MEDICO [Member] — Fri, 01 Aug 2008 20:55:31 +0000

Well, the @live-rebuild set is really only intended as an interim solution until bug 182028 has been implemented in a future EAPI. See bug 233589 for an alternative way that we might implement @live-rebuild using a new RESTRICT value (that doesn't require an EAPI bump).