On Wed, Jun 03, 2020 at 06:29:37PM +0200, Pavel Raiskup wrote:
On Wednesday, June 3, 2020 5:05:32 PM CEST Quentin Barnes wrote:
> On Tue, Jun 02, 2020 at 11:19:11PM +0200, Miroslav Such?? wrote:
> > Dne 02. 06. 20 v 23:02 Quentin Barnes napsal(a):
> > > 2) the "kernel-rpm-macros"
> > > package needs to be added to the @buildsys-build group for Fedora
> > That should be a final solution.
> > Variant is that `fedora-rpm-macros` will requires
> > > (or added to the "config_opts['chroot_setup_cmd']=..."
cfg line for
> > > CentOS/RHEL).
> > This is quick'n'dirty hack to unblock you for local builds and for
> I meant that CentOS/RHEL doesn't have a @buildsys-build. Instead, it
> uses a hardcoded list. For CentOS/RHEL, the equivalent fix would be
> to update their hardcoded list.
At least in Fedora, I checked few Koji builds for EPEL 8 and I don't see
kernel-rpm-macros in the buildroot installation transactions. So it is not in
the build group.
As long as the package isn't in default minimal buildroot, it is not correct
thing to just put the package into 'chroot_setup_cmd'.
Okay, let's break that down. What do you consider the "rules" for what
packages should be part of 'chroot_setup_cmd'?
As a mock user, my reverse engineering angle has told me that the
packages listed in the 'chroot_setup_cmd' macro are there for one of
two reasons. Either:
1) They are system packages provided by the OS that are used by most
package builds, and for good or ill, that way packages don't have
to list them as an explicit BuildRequires: dependency, but they
could have. These are ones like tar, gcc, and make.
2) They are system packages provided by the OS that are needed for
parsing or processing spec files. These are ones like bash,
redhat-rpm-config, and rpm-build.
If these aren't the reasons for why there are packages in
'chroot_setup_cmd', can someone better state what they are?
(A possible alternate meta-rule for the 'chroot_setup_cmd' macro for
RHEL/CentOS mock configs could say be feature eqivalent to Fedora's
@buildsys-build yum group?)
In my list of reasons, the kernel-rpm-macros package obviously falls
into category #2.
For RHEL, 8 adding back the %kernel_module_package (and kmodtool and
others) by adding kernel-rpm-macros rpm to chroot_setup_cmd is to
recover lost functionality.
As mentioned, before RHEL 8 (and current Fedoras), %kernel_module_package
macro was provided by /usr/lib/rpm/redhat/macros in the already
included redhat-rpm-config package. Parts of redhat-rpm-config got
spun off into kernel-rpm-macros. (As Neal pointed out in another
post, whether that should have been done or not by Red Hat or
Fedora devs is another issue, but it was done.) My request to add
kernel-rpm-macros to chroot_setup_cmd is to simply restore previous
functionality now missing by that OS change.
If feature-parity among supported OSes is not a goal of mock, then
I'd better understand the reason for leaving in this breaking change.
Plain mock would behave
differently from koji from this POV.
I'm not following what you mean. I can read several possible
interpretations in your phrasing. Could you explain further to
I'm not sure how the package is supposed to work, but perhaps you
can take a
look at `chroot_additional_packages` mock config option, to work-around things.
How which package is supposed to work?