I use a buildhost for each of the 4 architectures I manage - binary
emtytree installs are not to bad. However the initial build for low
power arm systems is measured in multiple days (for just the initial
toolchain, not hours :(. Only minor problems so far though which is
good. At least it can build while online, unlike fresh installs which
mean lots of downtime and more work for me in configuring.
BillK
On 9/4/24 05:14, Eli Schwartz wrote:
On 4/8/24 10:03 AM, Dr Rainer Woitok wrote:
Greetings,
the upgrade on my old laptop with two 2.7GHz Dual-Core Skylake proces-
sors took slightly more than 2 hours for the manual upgrading of "bin-
utils", "gcc" and "glibc", and slightly more than 21.5 hours for the fi-
nal upgrade of "@world", which had to process a total of 1061 packages.
I'm wondering whether a fresh install from a stage 3 "tar" ball would
have been faster?
If you're okay doing a fresh install from a stage3 tar, which is faster
at least to install the base system because it is all precompiled and
you are not building the packages yourself, then I would assume you're
also okay doing the update using the gentoo.org official binhost.
They're both just the binaries that Gentoo's release automation builds
for you. Extracting a bunch of gpkgs is much faster than compiling them,
and not too much slower than extracting a single stage3 tarball.
It also has the advantage that for amd64, more than just the stage3
package set can be sped up like this -- and you don't have to rebuild
the installation, recreate @world, backup and restore user data, etc.
Just enable the binhost and then do the same -e @world you were doing
without the binhost. :)
My first Gentoo installation on this laptop back in mid 2019 used pro-
file 17.1 (which is still marked "experimental", by the way). Now, less
than five years later this profile set is deprecated. Is five years a
common intervall between enforced Gentoo profile upgrades?
Well, 13.0 -> 17.0 -> 17.1 -> 23.0 so I suppose you could say they are
fairly long intervals, yeah.
As far as it being marked experimental: it was dropped from stable
during the 23.0 announcement, but is being marked as stable again:
https://github.com/gentoo/gentoo/pull/35871
Rationale:
"""
Making 17.1 exp immediately gives the impression that it's formally
deprecated, which it isn't yet.
"""
