With BLS the grubby tool isn't used when new kernels are installed, since
the bootloader config files don't have to be edited anymore. But u-boot
doesn't have BLS support yet, so on ARMv7 installs the old grubby tool
needs to be installed.
That's why commit 4c2694e1d8 ("Move grubby and grubby-deprecated from
@core to @arm-tools") moved the grubby-depracted package to @arm-tools.
But it also moved the grubby package and while this isn't needed during
install on other arches, it may be useful for users to manage their boot
menu entries.
Suggested-by: Adam Williamson <awilliam@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Adding them into @core was supposed to make them show up in some
install trees, according to the commit message, but it broke
regular BLS installs:
https://bugzilla.redhat.com/show_bug.cgi?id=1654036
which is obviously a major problem. I *think* moving the entries
to arm-tools should ensure the packages are in the relevant trees
without breaking BLS installs.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
For https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot.
glibc has Requires:glibc-langpack and Suggests:glibc-all-langpacks.
glibc-minimal-langpack has Provides:glibc-langpack, so if it is explicitly
pulled in, glibc-all-langpacks will not be installed (unless it is pulled in
through some other means).
Uses of (LANG|LC_.*)=.._..\.(UTF-8|utf8) have been either removed, or updated to
C.UTF-8, or BuildRequires: glibc-langpack-.. have been added, so it should be
OK to do this change now.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
If they are "mandatory", then attempting to install them atop a
system installed with another variant generates a conflict. A
"default" package gets ignored by DNF.
This patch is a pre-requisite to a larger effort to simplify the
variant handling in the fedora-release package.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
As per the previous batch, fix more references to packages that
don't exist. This should cover all the remaining 'not found on
any arch' cases. Again I tried to check the reason for all cases
and provide appropriate replacements where possible.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There are a lot of comps entries pointing to packages that just
don't exist any more. Note that group installs don't follow
Provides: or Obsoletes: or any of that jazz, the package must
exist under the exact name listed in comps.
This is a first set of fix-ups for these (as I've been working
on it all afternoon and am tired now). I looked into the reason
why every single one does not exist any more. Some had obvious
replacements, so I used them. Some did not, so I just took them
out. These are all packages that no longer exist on *any* arch,
I'm dealing with the 'package exists on only some arches' entries
later.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The cockpit metapackage is meant to control the minimal and recommended
parts of the default installation. This replaces
cockpit-{bridge,shell,ws}.
Also add cockpit-packagekit, as that is the enabler for installing other
cockpit extensions and required packages that Cockpit can control (such
as nfs-utils, firewalld, dnf-automatic, or pcp), and provides Software
Updates, which is an important system administration task on every kind
of installation.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1628457