I understand the desire for this feature but there are several downsides, too:

• it still adds a significant penalty as doing this requires us to build module-build-macros again and, depending on the situation, regenerate the repo up to three times per package
• it essentially introduces new buildorder subgroups, stopping us from building anything else in parallel, otherwise it would be affected by those extra, not-so-per-package-anymore macros

Imagine a module with three groups, 10 packages in each. One of the packages in the middle group uses this feature. What you do is:

• build module-build-macros with the initial module-wide macros
• regenerate the repo
• build the first group in parallel
• regenerate the repo to make sure these are in the buildroot
• now yo ucan build nine packages of the second group in parallel
• build module-build-macros with the per-package macros in it
• regenerate the repo, putting the nine packages in there, as well as the macros
• build the single package
• build module-build-macros without the per-package macros
• regenerate the repo
• build the remaining 10 packages in parallel

You could switch the order of the second group packages to first build the one and then the nine on parallel. That would need to be defined. It also differs in the buildroot contents -- people would need to be aware of that. Anyway, compare it the current situation:

• build module-build-macros with the initial module-wide macros
• regenerate the repo
• build the first group in parallel
• regenerate the repo
• build the second group in parallel
• regenerate the repo
• build the third group in parallel

I'm still not convinced it's worth the hassle.

Given the grouping limitations, perhaps "per-group" macros would be feasible? That would make it more explicit that all the modules in a group shared their module-build-macros, and would be sufficient to cover most cases using the following model:

• build module-build-macros with the initial module-wide macros and any group 1 specific macros
• regenerate the repo
• build the first group in parallel
• if either group 1 or group 2 defined macros, build module-build-macros with the initial module-wide macros and any group 2 specific macros
• regenerate the repo
• build the second group in parallel
• if either group 2 or group 3 defined macros, build module-build-macros with the initial module-wide macros and any group 3 specific macros
• regenerate the repo
• build the third group in parallel

Yes, this would be possible and would work fine. However, you don't get the fine-grained per-package control with this. I see very little difference compared to module-wide macros.

Do you have a specific example of where defining a module-wide macro would be harmful or in conflict with something else and these per-group macros would help you avoid that?

Not currently, as python-maint's plan for handling the Python module bootstrapping is to have the module that sets the bootstrap macros be a separate module (so you can build and install that module once to bootstrap a pristine buildroot, and then switch to the regular Python module).

If there's no any real world use case for this feature, I'd rather not implement it then.

Technically, in Koji there can be multiple active repos per build tag, so you could do something like:

• build multiple module-build-macros with different macro sets (in parallel)
• sequentially tag different module-build-macros, one after another
• generate multiple repos, each for different event (and different module-build-macros), in parallel (repos can be generated from set of packages tagged at any point of time in the past)
• run multiple component builds, all in parallel, from appropriate repos
• repeat above steps for all buildorder groups

@psabata Is there any news on this?
macros per package or macros per group would be a very useful feature when converting apps to flatpaks.

Ability to define macro per rpm built for flatpak would be really, really useful.
I just spend whole day trying to build macros so they don't run in every application but only single one just to get through some dependency builds.

@jaydoubleu I don't think so, no. Although I'm not actively involved in this project anymore and might have missed something.

modulemd is processed by libmodulemd, hosted on Github. That repo also holds the current specs and v3 is under way. MBS (fm-orchestrator) is also still active.

I'm going to close this here as this implementation is dead.