public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Multiple emerges in parallel (was: [RFC] RESTRICT=parallel for builds that can't be executed in parallel)
Date: Wed, 14 Apr 2010 18:47:10 +0000 (UTC)	[thread overview]
Message-ID: <pan.2010.04.14.18.47.09@cox.net> (raw)
In-Reply-To: 20100414181029.GC30025@hrair

Brian Harring posted on Wed, 14 Apr 2010 11:10:29 -0700 as excerpted:

>> The next thing is aborting merges. When running multiple emerges,
>> aborting one of them is as simple as pressing ^c. With daemon, we would
>> have to implement an ability of aborting/removing packages in runtime
>> -- and that would be another example of dependency tree mangling.
> 
> 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.

Umm... I think you two are using the same words for different things.

Definitely, aborting qmerge (transfer to the live filesystem) isn't a good 
idea, but in context, it's plain that MG's talking about the entire merge 
process, from setup, unpack and prepare thru qmerge and postinst (which is 
how the terms are used in the ebuild qmerge vs. ebuild merge context as 
well).  Clearly the entire merge doesn't need to be atomic, or we'd not be 
talking about parallel merges in the first place, nor would we have 
available all the individual ebuild <command> substeps.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




  parent reply	other threads:[~2010-04-14 18:48 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
2010-04-14 18:47         ` Duncan [this message]
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=pan.2010.04.14.18.47.09@cox.net \
    --to=1i5t5.duncan@cox.net \
    --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