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 > > > 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 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 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. > > 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 in > 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 that list. 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 > > > > Pavel > > > > Quentin Quentin _______________________________________________ buildsys mailing list -- buildsys@lists.fedoraproject.org To unsubscribe send an email to buildsys-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/buildsys@lists.fedoraproject.org
