Gavinmc42 wrote: ↑Sun Dec 30, 2018 3:15 am
Why is "apt-get install Warzone2100" much faster than "emerge Warzone2100"?
Using Gentoo's emerge stuff seems to take hours to do.
That's because with Gentoo, which is primarily a
source-based distribution, unless the package in question has previously been built as a binary with the
same version, USE flags, deps etc. as you require,
and has then been placed in an accessible binhost, emerge will compile it locally, from source - which, obviously, takes much longer to do than installing a pre-built binary (which is what you will essentially always be doing on
binary distros like Raspbian).
For the
gentoo-on-rpi3-64bit image, I maintain a set just over 1,000 prebuilt packages on the isshoni.org binhost. At approximately weekly intervals, on my main buildserver I automatically update the Portage tree (a list of "ebuilds", official Gentoo recipes for building packages from source), and attempt to build any revbumped or version-bumped packages. This generally thows up a few problems which are fixed with masks (inhibiting certain versions), keywording (stating that certain packages notionally only available on amd64 will also build OK on arm64, for example), USE flags (specifying which high-level configuration directives should apply to each package), patches etc. Once done, the resulting binary packages (most of which are built using an RPi3 and
distcc, but some of which (e.g., chromium) require a
QEMU user-mode binfmt_misc chroot) are pushed to the
binhost, the tweaks (masks, keywords, USE flags etc.) are added to the
custom profile, patched ebuilds are released into the
rpi3-overlay tree, and finally the "gated" copy of the main gentoo tree is updated. Once this is done, gentoo-on-rpi3-64bit users are able to pick up the changes using genup, and (unless they have gone off-piste with USE flags etc.) will find all necessary packages already available as binaries on the binhost. In this way the update time for end-users is kept manageable, whilst still providing the full flexibility of Gentoo should that be required (turning off the "bindist" USE flag to build patent-encumbered codecs, for example, should the end user want to so this (at their own risk!!) for one or more packages).
This basically means that the gentoo-on-rpi3-64bit system is more a 'mini-distribution' than an image. There are
just over 1,000 packages used on the image (almost all of which are maintained on the binhost). This is << the 35,000 contained in a full-blown binary distribution like
Raspbian, and also << the 20,000 or so packages for which Gentoo maintains ebuilds (with, however, generally multiple versions and often multiple slots, and with the customization flexibility of USE flags of course, so the number of available variants is
much larger than 20k) so, if you ask Portage to emerge something that isn't prebuilt, you'll end up compiling it locally.
There are other points to note too, however. Looking at the ebuild for
games-strategy/warzone2100 I notice that it isn't keyworded for arm64. If you accepted Portage's default "resolution" to this (which would be to keyword this package and any similarly-disposed deps "**") you'll end up with a nasty dependency tangle - "**" means to use the "tip of source-control" builds: it is much better to create explicit "*" or "* ~*" entries for each affected package (this means to accepts as a build candidate a version that has been marked as stable on
any architecture, or as stable or testing on any architecture, respectively). You do this by creating entries in /etc/portage/package.accept_keywords/<pkgname>. You can see examples of doing this in the
custom profile.
hth, sakaki
.
