I think that complete module builds (i.e. CG builds) should be tagged with update candidate tags corresponding to all platforms they can be installed on.
For example, in Fedora production I submitted maven-master-20180406164508.89d012dc module build. Upon completion it was tagged only as f29-modular-updates-candidate. Since the module build can run on any platform (it requires "platform: "), I would expect it to be tagged with all update candidate tags (both f29-modular-updates-candidate and f28-modular-updates-candidate). Lack of f28-modular-updates-candidate tag prevented me from submitting Bodhi update and I had to tag the build manually.
This seems like a Bodhi issue since MBS shouldn't be touching the fxx-modular-updates-candidate tags. @jkaluza can you confirm? Perhaps I misunderstood the issue.
Bodhi doesn't tag anything as updates-candidate, it's responsibility of the build system. And MBS did tag the build, but only with f29-modular-updates-candidate. It did not tag it with f28-modular-updates-candidate even though the module build was eligible for submitting as update for Fedora 28.
$ koji list-history --build maven-master-20180406164508.89d012dc | head -2
Fri Apr 6 20:22:37 2018 maven-master-20180406164508.89d012dc tagged into f29-modular-updates-candidate by mbs/mbs.fedoraproject.org
Fri Apr 6 20:30:35 2018 maven-master-20180406164508.89d012dc tagged into f28-modular-updates-candidate by mizdebsk
Any update? This issue causes broken modules to be shipped in rawhide.
@mizdebsk I don't understand why you buildrequire platform f29 but require any platform. My suggestion is to use module stream expansion, and require and buildrequire platform: , then separate module builds will be built for each available platform. Each build will then be tagged appropriately.
To clarify, the CG tag is based on the platform you buildrequire, not require.
Java software can be build just once and ran on any platform ("build once, run everywhere").
Tags should be based on target platform, not build platform. It is perfectly fine to build module on f29 and have it only available only on f28. In this case the module should be tagged for f28-modular-candidate only.
Let me explain the problem in more detail on example of some hypothetical application called App. (But this issue is not only hypothetical, javapackages-tools module in Fedora is affected by it.)
Therefore app, in above situation, app module buildrequires plaftorm: [f29], but requires platform: [-f29].
The issue is that MBS unexpectedly tags resulting module build with f29-modular-candidate. Then the module is autosigned and pushed to rawhide. Module which is not even installable on rawhide. What's worse, module packager has no way to prevent shipping broken (not installable) app module in rawhide as everything happens automatically.
IMHO to fix this situation MBS should tag the module with tags corresponding to platforms that the module is targeted for, not platform on which the module was built. In the example case above, MBS should tag the module build with all tags except f29-modular-canditate, which is exactly the opposite from what it currently does.
@ralph and @psabata could you please provide your opinions on this?
Any update on this issue?
Incorrect tagging has recently lead to package breakage in rawhide - module maintainer submitted a build of module that works on all platforms and expected the build to be tagged as candidate for all platforms, including F29 and rawhide. This did not happen - MBS tagged module build with f28-modular-updates-candidate only. This lead to package breakage.
I believe this is addressed by the new message-tagging-service. This allows builds to be tagged with multiple tags based on configuration.
It's currently deployed in internal infrastructure. It's been requested for fedora.
Ok to close this?
MTS with appropriate configuration may be able to fix the problem. So feel free to close this issue.
Metadata Update from @lucarval:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
to comment on this ticket.