This was a place I missed where /etc/portage is set up. Because of it,
user patches for sys-devel/gcc were not picked up.
Also stop using deprecated PORTDIR and PORTDIR_OVERLAY getters. We
still set those variables, but we will drop them eventually.
Normally `ln -sf path/to/target at/name` will create a symlink at
`at/name` that points to `path/to/target`. But if `at/name` already
exists and is a directory or a symlink to some other directory, then
this command will create a symlink at `at/name/target` pointing to
`path/to/target`. There is an ambiguity between 1st and 3rd form of
`ln` (please refer to `man ln` for the available invocation forms). It
can be disambiguated by using the `-T` flag to force the 1st form.
In our case, if `/etc/portage/patches` symlink already existed and was
pointing to `<coreos-overlay>/coreos/user-patches`, we ended up with a
useless symlink at `<coreos-overlay>/coreos/user-patches/user-patches`
pointing to `<coreos-overlay>/coreos/user-patches`.
Use FLATCAR_DEV_BUILDS only for setting up binpkg URLs, ceding the SDK
tarball URL role to the new FLATCAR_SDK_SERVERS variable. That way we
can still set up binpkg URLs the way we used to do so far and set up
SDK tarball URLs differently.
For two-phase SDK build, we would like to use intermediate SDK as a
seed. This SDK is only available on bincache, but previously only
nightly builds could use bincache as the source of SDK tarballs. Now,
with the URL split, we can set up the builds to use both bincache and
the release server, where release builds will prioritize release
server over bincache, and developer builds - bincache over release
server.
When setting up portage configuration, we set up a symlink in
${ROOT}/etc/portage/patches that points to the coreos/user-patches
directory inside the coreos-overlay. That way, we can add our custom
patches to coreos-overlay without the need for moving the packages
from portage-stable to coreos-overlay only to apply an extra patch.
