Per discussion on #1169979, fontconfig upstream think they have
the bugs licked, so this shouldn't be needed any more. We need
to check the nightly lives after this and see if their caches
are now correct.
This effectively reverts the recent change by rdieter, without undoing
the refactoring.
As per the IRC discussion, it looks like caching the metadata is not all
that helpful with Apper or Muon (and I doubt it is actually helpful with
ANY frontend, because updates will necessarily be outdated, and even the
Everything repo usually changes one last time after the last RC, to
officially push packages that the RC took from a side repo), we would
only be increasing our spin size with stale metadata.
Fedora has gotten significantly bigger since we started doing final TCs
and even between final RCs. I am not sure why. But this cut will get
the Games spin safely under 4 GiB.
As livecd-creator is still yum based, we only get yum's yumdb during
live image composes. To work this around, this commit adds a %post
script to fedora-live-base.ks to migrate yum's yumdb over to dnf.
https://bugzilla.redhat.com/show_bug.cgi?id=1274319
Instead of taking the metadata from PackageKit-cached-metadata package
as we were doing previously, copy it over directly during the compose
from https://kojipkgs.fedoraproject.org/mash/
This makes it much less error prone as we always get the very latest
metadata, and makes maintenance much simpler as we don't need to roll
PackageKit-cached-metadata by hand. Users are also going to appreciate
this because it makes post-GA updates smaller as they won't have to
download updates for the PackageKit-cached-metadata subpackage each time
PackageKit gets updated.
We have had -kbd in the kickstart for a long time, but because of BZ#1199868
it wasn't actually getting excluded. Not having it causes
systemd-vconsole-setup.service to fail so we are adding it back for now.
Additionally we need to add back plymouth to cover up the subsequent failure
of systemd-vconsole-setup.service. See BZ#1272684.
Workaround BZ1262040 by removing the --instLangs arg from the
%packages line and rely on our previous hack to manually remove
langs after install. This fixes BZ1261249.
Signed-off-by: Kushal Das <kushaldas@gmail.com>