There is a dependency loop when systemd is build with cryptsetup
like systemd -> cryptsetup -> lvm2 -> baselayout -> systemd. Since
CoreOS always installs a good baselayout, it makes sense drop the
lvm2 dependency and turn it into a conflict with bad versions. It
also has a runtime dependency loop on systemd, so make that into a
build dependency.
This also stabilizes the version that was being used by arm64,
updating amd64, to bring the architectures into alignment.
Changes include:
* Add cros_workon bits
* Define and use the symlink-usr flag
* Drop SELinux policy and udev init scripts dependencies
* Drop all patches since the source is from Git
* Switch /etc/resolv.conf to the old one
* Drop the D-Bus policy path to keep the default
* Use CoreOS NTP servers
* Install PAM files into /usr
* Set the timesyncd epoch
* Don't use default DNS servers
* Use legacy cgroups (https://github.com/docker/docker/issues/28109)
* Rewrite basically the entire install step
* Drop the systemd-bus-proxy user since the program is long gone
Prior to this, "${P}" would match upstream gentoo's distfile cache of
containerd, and that tarball would be used regardless of our SRC_URI
changing as we bumped the commit hash.
That resulted in us having an incorrect version of containerd installed
(and lying about the commit hash in --version to boot. Yikes!)
This fixes it by ensuring our package name actually uniquely identifies
the containerd package.
The choice to use the number of commits since the version as the patch
number is fairly arbitrary, but seemed like a sane and comparable number
to choose.
Due to containerd's somewhat fragile versioning, this number is not
technically unique (since there the v0.2.3 bump is commit to multiple
branches), but we can deal with issues if they happen.
Alternative fixes, such as FETCH_RESTRICT or other means of fooling the
cache logic, are more error prone and less faithful to portage's intent
that ${P} does uniquely identify an upstream source.
A different fix would be to use a CROS_WORKON style process for
containerd. There's no particular reason that approach is being avoided
other than the need to hack on containerd has so far been fairly small.
We can be more sloppy with versioning if/when we switch containerd over
to that process.
The choice to rename to 0.2.3 is because that commit (see
containerd/version.go) chooses to call itself 0.2.3, though it's newer
than the v0.2.5 tag. Docker 1.12 actually used a commit that contained
the 0.2.5 tag.
This is only an issue when the glibc versions differ between the
SDK and the sysroot. The M4 library detection functions in gettext
do bad things on their own, so bypass them.
The Ignition units are only used in the initramfs and are intertwined
with several other units in bootengine. Move them into bootengine for
simplicity.
This updates the ebuild to include a patch number indicating changes
since the referenced version number.
This is because docker uses untagged versions of runc, and so we need
additional version information.
Prior to this change, the runc ebuild inadvertently used the upstream
distfile cache of runc's distfile, regardless of the commit referenced
and the -r bumps.
This also re-fixes CVE-2016-9962. The patch for that vulnerability was
dropped once we thought the commit contained the fix, but since the
commit was being ignored and the fix never made it into any tagged
release, we accidentally regressed.
Finally, tihs updates the selinux patch. This was sourced from
projectatomic/runc on the docker-1.13.1 branch.
