On Fri, Jun 05, 2020 at 10:28:32PM +0200, Pavel Raiskup wrote:
On Friday, June 5, 2020 4:43:20 PM CEST Quentin Barnes wrote:
> On Wed, Jun 03, 2020 at 06:29:37PM +0200, Pavel Raiskup wrote:
> > As long as the package isn't in default minimal buildroot, it is not
> > thing to just put the package into 'chroot_setup_cmd'.
> Okay, let's break that down. What do you consider the "rules" for
> packages should be part of 'chroot_setup_cmd'?
As I looked at the problem -- mock's default behavior should be the same
as Koji's behavior, and vice versa. As much as reasonably possible...
Otherwise people will come and solve troubles that something works here,
but doesn't work there..
I've only tinkered a little with Koji many years ago. I only use
mock to build one-off RPMs, so I'm not sure how Koji's behavior
differs from mock in this case. Can you clarify or point me to docs
to better understand your point?
> As a mock user, my reverse engineering angle has told me that
> 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.
Agreed, except that mock is not the place to decide what will be in
minimal buildroot. That is per-distro decision. Mock's defaults are just
trying to mimic what is set per-distro.
I didn't realize that was published, at least for RHEL. Years ago
as a RHEL customer, I asked our TAM (via a case ticket) what the
minimal set was, but was told they don't publish it publicly.
Back the week of the announcement of Red Hat usurping CentOS (2014),
I had a nice 1-on-1 chat with Johnny Hughes and how he has to
reverse engineer how Red Hat defines each major RHEL release's build
stages and environment. He was hoping that after the adoption, that
build environment would be published openly and shared. I'm not
sure that ever happened.
> 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?)
Exactly, that is my understanding. The list of packages is given by the
"build" group which only exists "internally" and isn't shipped
mirrored (public) set of repositories.
That makes sense.
Btw., for internal build group, you probably could try:
$ mock -r epel-8-x86_64 --enablerepo local --install @build
> In my list of reasons, the kernel-rpm-macros package obviously falls
> into category #2.
Did you try to ask Fedora to put that package to the "default" epel
minimal buildroot set of packages?
Ah! I had noticed before my last reply that 'kernel-rpm-macros' was
not in Fedora's @sys-build list where a lot of the other '*-srpm-macros'
rpms with their droppings in /usr/lib/rpm/macros.d/* were. It looked
like to me this was an oversight and 'kernel-rpm-macros' should be in
So it sounds like the correct approach is to not discuss the
inclusion of 'kernel-rpm-macros' with this group, but to approach a
different Fedora group. Once they agree (or disagree) that decision
will get reflected back here. Right?
I'm not active in Fedora, so if anyone can suggest on what place and
method (which email lists, IRC channels, BZ tickets, etc.) I should
start this discussion with Fedora, please let me know.
> > Pavel