From: tuxic@posteo.de
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] New profile 17: How urgent is the rebuild of world technically?
Date: Sun, 3 Dec 2017 04:45:59 +0100 [thread overview]
Message-ID: <20171203034559.qlwbla6hvkjnpn32@solfire> (raw)
In-Reply-To: <20171203043531.28dd18bb@lexx>
On 12/03 04:35, Heiko Baums wrote:
> Am Sun, 3 Dec 2017 04:26:55 +0100
> schrieb tuxic@posteo.de:
>
> > If the compilation will fail at a certain point (and it will fail,
> > since this is a complete new thing) -- would it be possible to resume
> > even some tweaks, hacks and patches (even certain recompilations)
> > would be needed in between?
>
> Just run `emerge -e --keep-going y @world`.
>
> > Can I stop a running emerge @world and resume later?
>
> Maybe with `emerge --resume`. But I don't know if interrupting this
> would cause some problems in this particular case.
>
> > How does a restarted emerge @world recognizes packages, which are
> > already compiled according to the new standard?
>
> It simply creates a list of the packages to be installed as usual and
> knows which of them are already installed and which are not. Then it
> recalculates the dependency tree as usual.
>
> Heiko
>
Hi Heiko,
...sorry my question was unclear.
Suppose one would do an emerge @world...and then BOOOM! a powerfailyre
would stop the whole thing. Further suppose the filesystem, the
hardware and anything has survived luckily -- only emerge @world needs
to be restarted.
And one does NOT an emerge --resume but an emerge @world.
In this particular case...how does emerge knows from the previous
emerge @world what packages has been recompiled already and are "PIE"?
How can I check, whether a binary is "PIE"-conform ("pie-conform" is
a freaky funny language hack :) ;) ) ?
Cheers
Meino
next prev parent reply other threads:[~2017-12-03 3:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-03 2:15 [gentoo-user] New profile 17: How urgent is the rebuild of world technically? tuxic
2017-12-03 2:30 ` Michael Orlitzky
2017-12-03 2:32 ` Adam Carter
2017-12-03 2:44 ` Michael Orlitzky
2017-12-03 3:26 ` tuxic
2017-12-03 3:35 ` Heiko Baums
2017-12-03 3:45 ` tuxic [this message]
2017-12-03 4:15 ` Heiko Baums
2017-12-03 9:53 ` Peter Humphrey
2017-12-03 11:56 ` Heiko Baums
2017-12-03 12:55 ` Dale
2017-12-03 14:09 ` Spackman, Chris
2017-12-03 14:16 ` tuxic
2017-12-03 14:39 ` Heiko Baums
2017-12-03 15:25 ` Peter Humphrey
2017-12-03 15:57 ` Neil Bothwick
2017-12-03 14:36 ` Heiko Baums
2017-12-03 14:27 ` Heiko Baums
2017-12-04 1:08 ` Dale
2017-12-04 1:18 ` Heiko Baums
2017-12-04 1:48 ` Walter Dnes
2017-12-03 5:26 ` Adam Carter
2017-12-03 10:51 ` Neil Bothwick
2017-12-03 3:47 ` Heiko Baums
2017-12-06 23:59 ` Frank Steinmetzger
2017-12-07 8:08 ` Neil Bothwick
2017-12-04 17:48 ` Stefan G. Weichinger
2017-12-04 20:21 ` Michael Orlitzky
2017-12-05 9:16 ` Stefan G. Weichinger
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=20171203034559.qlwbla6hvkjnpn32@solfire \
--to=tuxic@posteo.de \
--cc=gentoo-user@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