From: "Michał Górny" <gentoo@mgorny.alt.pl>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Multiple emerges in parallel (was: [RFC] RESTRICT=parallel for builds that can't be executed in parallel)
Date: Wed, 14 Apr 2010 20:35:27 +0200 [thread overview]
Message-ID: <20100414203527.6d43ad60@pomiot.lan> (raw)
In-Reply-To: <20100414181029.GC30025@hrair>
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
On Wed, 14 Apr 2010 11:10:29 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Running multiple emerge's in parallel is unsafe due to the fact
> they've got two potentially very different plans as to what is being
> done, and that there is no possibility to ensure that pkg D that PM-2
> is building isn't affected by PM-1 building something (upgrading a
> dependency of pkg D for example).
>
> Yes you can get away with it occasionally, that doesn't mean it's
> safe however.
I agree with you -- such operations should be performed with
appropriate caution, on user's own responsibility. But this doesn't
mean we should prevent user from being able to do that.
> Aborting merges is a very, very bad idea. Consider a pkg that has
> dlopen'd plugins, and just went through an ABI change for that
> interface. If you interupt that merge it's entirely possible you'll
> get just the lib merged (meaning a segfault on loadup of the
> plugins), or vice versa (old lib is still in place, but new plugins
> are there).
>
> Don't abort merges- that really should be effectively an atomic OP,
> not interuptible.
Sorry, by 'aborting merges' I meant rather aborting the build process
before the 'merge' phase -- or even aborting it before it is started
(i.e. before it unpacks a load of files into ${PORTAGE_TMPDIR}
without sufficient space).
--
Best regards,
Michał Górny
<http://mgorny.alt.pl>
<xmpp:mgorny@jabber.ru>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-04-14 18:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-14 2:12 [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel Zac Medico
2010-04-14 5:45 ` Michał Górny
2010-04-14 6:10 ` Brian Harring
2010-04-14 7:06 ` [gentoo-dev] " Duncan
2010-04-14 9:02 ` Brian Harring
2010-04-14 14:20 ` [gentoo-dev] Multiple emerges in parallel (was: [RFC] RESTRICT=parallel for builds that can't be executed in parallel) Michał Górny
2010-04-14 18:10 ` Brian Harring
2010-04-14 18:35 ` Michał Górny [this message]
2010-04-14 18:47 ` [gentoo-dev] " Duncan
2010-04-14 6:46 ` [gentoo-dev] [RFC] RESTRICT=parallel for builds that can't be executed in parallel Justin
2010-04-14 12:58 ` Michał Górny
2010-04-14 13:03 ` [gentoo-dev] " Duncan
2010-04-14 23:36 ` Ryan Hill
2010-04-21 10:34 ` [gentoo-dev] " Luca Barbato
2010-04-30 16:32 ` Enrico Weigelt
2010-04-21 10:38 ` Luca Barbato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100414203527.6d43ad60@pomiot.lan \
--to=gentoo@mgorny.alt.pl \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox