public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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 --]

  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