ignatenkobrain reported a new issue against the project: `releng` that you are following: `` * Describe the issue
Today we've encountered issue that if your modulemd contains something like
```yaml - buildrequires: platform: [f29] requires: platform: [] ```
MBS doesn't tag it properly into f28-* because it checks for buildrequires and not for requires. Which is wrong: https://pagure.io/fm-orchestrator/issue/974
However, @puiterwijk mentioned that bodhi doesn't support this either because it would pick first tag instead of creating updates for multiple ones. It seems that bodhi would need to change some core parts for this.
I'm submitting this ticket just to make sure that work is scoped and if can't be completed before F29 bodhi activation point, could be workarounded.
* When do you need this? (YYYY/MM/DD)
F29 Bodhi activation point.
* When is this no longer needed or useful? (YYYY/MM/DD)
When modularity dies.
* If we cannot complete your request, what is the impact?
One of the main use-cases for modularity doesn't work. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
till added a new comment to an issue you are following: `` Please also file and link the ticket for Bodhi here. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
puiterwijk added a new comment to an issue you are following: `` 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 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.
[1]: https://fedorapeople.org/groups/schedule/f-29/f-29-releng-tasks.html ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
mattdm added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
bowlofeggs added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
jperrin added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
puiterwijk added a new comment to an issue you are following: `` @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 to do so. They could (as I was explained 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
mattdm added a new comment to an issue you are following: `` 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? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
jkaluza added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
mattdm added a new comment to an issue you are following: ``
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? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
jkaluza added a new comment to an issue you are following: `` @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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
mattdm added a new comment to an issue you are following: `` 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. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
syeghiay added a new comment to an issue you are following: `` @bowlofeggs , are you still planning to work on this? ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
bowlofeggs added a new comment to an issue you are following: `` Hi @syeghiay!
This is not on my team's priority list, so we are not currently planning to work on it. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
The status of the issue: `Build once, run everywhere seems to be pretty unsupported (modularity)` of project: `releng` has been updated to: Closed as Get back later by syeghiay.
syeghiay added a new comment to an issue you are following: `` Closing ticket for now. Will consider at another time. ``
To reply, visit the link below or just reply to this email https://pagure.io/releng/issue/7662
The status of the issue: `Build once, run everywhere seems to be pretty unsupported (modularity)` of project: `releng` has been updated to: Open by ignatenkobrain.
rel-eng@lists.fedoraproject.org