Please also file and link the ticket for Bodhi here.

This will not be completed before F29 bodhi activation.
I'd also like to point out this piece of the F29 Releng schedule 1: Compose tooling completed deadline Wed 2018-07-18 Wed 2018-07-18 0.

Any changes to MBS, bodhi or the others tools would fall under this, and the date has passed.
In addition, this is significant, previously unscoped, work for Bodhi.

Personally, I also think it is not a great idea to manually tag things into f28 built for f29 without Bodhi supporting this, because that means that after f29 bodhi activation, you can no longer update the application in either f28 or f29 (one at your pick), which means that if there's any security vulnerabilities or serious bugs, we have no way of shipping updates to shipped packages.

Without comment on schedule or anything, I do want to affirm that this is definitely one of the main things I want from modularity — "One of the main use-cases for modularity doesn't work" is not hyperbole.

If this was a primary use case, the feature request should have been communicated to us much earlier than last week. Infrastructure and Release Engineering both need time to gather requirements, plan the work, perform the changes, and test the changes. The Bodhi activation point is a few weeks away, and we do have other work planned for the period between now and then that was communicated in advance, and this is a significant change request that I would estimate to take months to plan, implement, and test.

Having reviewed some of the high level detail around where this would impact bodhi and mbs, I feel that moving forward on this for the F29 bodhi activation could best be characterized as "reckless".

If there's a suitable workaround, we should look to that. Otherwise I'm happy to put this on the schedule for F30 and to help scope and plan necessary changes.

@mattdm I would like to point out that the problem with this module is not the case that we can't build it against f28 per se. but the fact that they want to reuse everything from the base platform (f29) to do so.
They could (as I was under the impression had been the goal) make modules of the dependencies, or make the dependencies as sub-build-steps in this module (With results not being shipped), which would then compile against the correct platforms, and work perfectly fine, without any further changes needed, right today.

The problem is that in this case, they're trying to use dependencies that are only packaged for f29 (and not in a module) to build modules that ship on f28, which is what I believe was never the intention: either build lower modules for the deps, or build the deps in the same module but unshipped.

I think the team didn't realize that this change was necessary to meet the requirement until recently — at least, that's what https://pagure.io/fm-orchestrator/issue/974#comment-523850 leads me to believe. That's unfortunate, but sometimes that's how things go.

And, yes, what @puiterwijk says in the comment above this one makes sense to me.... am I missing something?

The workaround for that "probably" (read further) is to build twice from the single modulemd.

You should be able to express the dependencies in modulemd file like this:

- buildrequires:
    platform: [f29]
  requires:
    platform: [f28]
- buildrequires:
    platform: [f29]
  requires:
    platform: [f29]

Once you submit the build to MBS, this should result in two builds (same name:stream:version, differen ":context"). Once the MBS issues 974 is fixed, MBS will tag these builds based on "requires" and not "buildrequires", so first nsvc will be tagged in f28 tag, second in f29 tag.

Bodhi should be OK with that. The only issue is I have no tested that MBS really behaves like that, but based on my memory of the code, it should.

The workaround for that "probably" (read further) is to build twice from the single modulemd.

Isn't this what the stream expansion is supposed to do?

@mattdm: Can you specify the question more? The module stream expansion in MBS works as expected and both original Igor's modulemd section and my section is handled by MBS using module stream expansion.

The difference is that in Igor's case, there is just single module build in Koji, which should be later tagged in both f28 and f29 tags, but that makes it impossible to ship such module using current Bodhi.

In my case, there are two module builds in Koji, one tagged in f28, another one in f29. Bodhi should be able to ship them.

From the module maintainer perspective, you still do single "fedpkg module-build" in both cases and the Igor's case is how modularity really should work in this case, but my way could work as workaround until we improve Bodhi.

Maybe I misunderstood, then. Please pardon me, as I'm trying to dig out of two weeks of PTO. I'm only concerned with the packager/user experience of: one module, but built into multiple Fedora releases (and ideally soon EPEL). Under-the-hood binary reuse isn't important to me.

@bowlofeggs , are you still planning to work on this?

Hi @syeghiay!

This is not on my team's priority list, so we are not currently planning to work on it.

Closing ticket for now. Will consider at another time.

There is nothing releng can do here, please create a bodhi ticket at https://github.com/fedora-infra/bodhi/issues if you still want this feature.

Thanks.