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