Since installing _sys-libs/glibc_ in the crossdev root overwrites the
libraries built by crossdev, Portage records the latter as needing to be
protected. This results in _everything_ being pulled in to
@preserved-rebuild, which ultimately does nothing since the preserved
library is never replaced. To avoid this pointlessness, we need to
disable the _preserve-libs_ feature when reinstalling _glibc_.
We also disable _protect-owned_ to avoid spam from Portage when
initially overwriting the libraries and headers in the crossdev root.
_crossdev_ sets `ACCEPT_KEYWORDS="${ARCH} ~${ARCH}" by default, even
when run with `--stable`. This can cause conflicts when the host system
does not accept ~arch, and may not be desirable anyway. Projects that
want to use ~arch can set it in their own `make.conf`.
The _u-boot_ package does not have any stable keywords, so we have to
explicitly accept it.
Instead of requiring every Aimee OS project to carry around a full
Portage configuration tree, including patches, saved configurations,
etc., we now support a "layered" configuration system. Aimee OS core
provides a base configuration that includes all settings, patches, etc.
common for all Aimee OS projects. At build time, this base
configuration is combined with the project's configuration, which need
only specify USE flags, etc. for that specific project. This should
make maintenance across multiple projects easier, and make getting a new
project started _significantly_ less cumbersome.
The 17.0 profiles are deprecated. Let's use the project's configured
profile at this stage, so as not to have to rebuild stuff because we
change USE flages, etc. once we set it later.
The modern profiles are all "merged-usr" by default now, so we do not
need that explicit step anymore.
In effort to support different builds of Aimee OS using the same
scripts, without necessarily having to fork this repository, the build
system now supports a `CONFIGDIR` setting. When this variable is set,
files defining the target environment, such as the lists of packages to
install, the kernel configuration, the Portage configuration, etc. are
found in the path it specifes.
The reference build, for the Home Assistant Yellow board, is configured
in the `yellow` directory. To build it, run:
```sh
CONFIGDIR=yellow ./vm-build.sh
```
Instead of copying the Portage configuration files to `/etc/portage` and
`/usr/${target}/etc/portage`, the build scripts now use the
configuration directories from the source directory. This avoids issues
with changes (especially removal of files) getting propagated to the
actual configuration paths.
Since we have to build *sys-libs/libcap* with the default Portage
configuration in order to avoid the circular dependency with PAM,
our configuration for binary package builds is not yet in place. We
need to explicitly specify where to put the built packages and enable
multi-instance packages.
Several packages end up with circular dependencies, depending on which
Portage profile is selected. The default profiles have a circular
dependency between *sys-libs/pam* and *sys-libs/libcap*. Systemd and
SELinux profiles have even more issues.
We can break the circular dependencies by explicitly building *libcap*
with`USE=-pam` first, which happens to be the default configuration
generated by `crossdev`. Then, we need to switch to a more complete
profile in order to build *glibc* and *util-linux*. At this point, the
build root should be complete enough to build anything without circular
dependencies.
Dustin