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: > > 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 "kernel-rpm-macros". > > > > > > > > > (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 > > > > testing. > > > > > > 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 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.. > 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. > 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. 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? > 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. Yes, I don't claim it shouldn't be there ... I just claim that it should be first in the Koji Fedora buildroots. > 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. It is not. When using mock, you basically "train" your builds for Fedora locally. It doesn't make much sense to succeed locally, and then submit the build to Koji and fail... Perhaps we can think about `fedora-kmod-rawhide-x86_64.cfg` config file if there's no other option. > > 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 clarify? Just the above ^^^. > > 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? I mean, I don't know how those macros are to be used... Whether it is absolutely necessary to have it in minimal buildroot or not (but now it seems like it needs to be there). In such case, you can absolutely set the `chroot_additional_packages` option in the meantime. Pavel > > Pavel > > Quentin > _______________________________________________ > buildsys mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > _______________________________________________ buildsys mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
