releng

#7963 Rawhide compose contains modules built for platform:f29
Closed: Fixed Opened by ppisar.

Closed: Fixed
Reopen Issue

Every module has a run-time dependency on a platform stream. The platform stream is uniq for each fedora release. That means you cannot inherit modules from Fedora 29 to Fedora Rawhide. Modules do not behave like RPM packages. The automatic inheritance makes the modules uninstallable.

Example is perl:5.26. Now the modular Rawhide compose contains perl:5.26:20180417112647:ccbeb30a module that was built for platform:f29 and this cannot be enabled on Rawhide (Fedora 30):

# dnf module enable perl:5.26 
Last metadata expiration check: 0:12:48 ago on Fri 07 Dec 2018 08:13:56 AM CET.
Error: Problems in request:
Modular dependency problem:
 Problem: conflicting requests
  - nothing provides module(platform:f29) needed by module perl:5.26:20180417112647:ccbeb30a-0.x86_64

I request you to stop distributing modules that are built for a different platform stream than the compose is made for. There is no point in distributing them.

(Notice: I'm just building perl:5.26 for platform:f30 now so this example will disappear.)

Inheritance does not come into picture here, the build is tagged directly in f30-modular.

$ koji buildinfo perl-5.26-20180417112647.ccbeb30a | grep Tags:
Tags: f29-modular f30-modular

In that case untag them.

$ koji list-tag-history --build perl-5.26-20180417112647.ccbeb30a | grep f30-modular
Tue Aug 14 19:27:58 2018: perl-5.26-20180417112647.ccbeb30a tagged into f30-modular by mohanboddu [still active]

@mohanboddu can you explain?

This is caused as part of branching, I guess we should find another way to handle the module builds then instead of cloning the tag with latest builds

https://pagure.io/releng/blob/master/f/scripts/branching/make-koji-release-tags#_66

CC: @sgallagh

Edited by mohanboddu

From irc:

[14:49:59] <sgallagh> mboddu: I have it on my TODO list to sit down with you and hash this out, but I'm currently overbooked until the new year :(
[14:50:27] <sgallagh> I cannot spare the time right now, sorry.

Creating fNN branches for modules name space repositories in dist-git is also wrong.
Edited by ppisar

@ppisar Yeah, that is fixed now.

Creating fNN branches for modules name space repositories in dist-git is also wrong.

@ppisar I see 2 perl module builds and 2 perl-bootstrap builds in rawhide

perl-5.26-20180417112647.ccbeb30a         f30-modular           ppisar
perl-5.26-20181207093623.d5758a6e         f30-modular           ppisar
perl-bootstrap-5.26-20180413143842.6c81f848  f30-modular           ppisar
perl-bootstrap-5.26-20181206150213.a5b0195c  f30-modular           ppisar

Based on the buildinfo, I guess we have to untag perl-5.26-20180417112647.ccbeb30a and perl-bootstrap-5.26-20180413143842.6c81f848, could you please confirm?

Yes, these two module builds are for platform:f29 and should be untagged:

perl-5.26-20180417112647.ccbeb30a
perl-bootstrap-5.26-20180413143842.6c81f848

However, Perl modules are not the only ones. Searching modulemd from the rawhide-modular repository for dependencies/requires/platform different from [f30] or [] I can see:

container-tools-2018.0-20180529173716.cb85db27
cri-o-2018.0-20180529183952.3ff668f0
docker-2017.0-20180409180031.3ff668f0
golang-ecosystem-2017.0-20180724154421.cbfb2833
mariadb-10.1-20180418185803.6c81f848
mongodb-3.6-20180601084133.6c81f848
pki-10.6-20180713022640.6c81f848
postgresql-9.6-20180429200004.6c81f848
reviewboard-2.5-20180409150256.88f8ec0d

These 9 module builds were also additionally tagged into f30-modular.

These 2 module builds were in f30-modular since the beginning, so it's probably a packaging bug:

stratis-master-20180927210300.337c62b4
stratis-master-20180927210300.7a127764

Yes, these two module builds are for platform:f29 and should be untagged:
perl-5.26-20180417112647.ccbeb30a
perl-bootstrap-5.26-20180413143842.6c81f848

I untagged the perl modules

$ koji untag-build f30-modular perl-5.26-20180417112647.ccbeb30a perl-bootstrap-5.26-20180413143842.6c81f848

However, Perl modules are not the only ones. Searching modulemd from the rawhide-modular repository for dependencies/requires/platform different from [f30] or [] I can see:
container-tools-2018.0-20180529173716.cb85db27
cri-o-2018.0-20180529183952.3ff668f0
docker-2017.0-20180409180031.3ff668f0
golang-ecosystem-2017.0-20180724154421.cbfb2833
mariadb-10.1-20180418185803.6c81f848
mongodb-3.6-20180601084133.6c81f848
pki-10.6-20180713022640.6c81f848
postgresql-9.6-20180429200004.6c81f848
reviewboard-2.5-20180409150256.88f8ec0d
These 9 module builds were also additionally tagged into f30-modular.

This is kinda expected for which we are working on a solution and will be probably fixed early next year. Until then, we will let them be unless someone complains about it or we have to test them individually and untag them if not working. I will see what I can do about it.

These 2 module builds were in f30-modular since the beginning, so it's probably a packaging bug:
stratis-master-20180927210300.337c62b4
stratis-master-20180927210300.7a127764

It was not a packaging bug, it was a mistake we made in assuming how the modules would be working.
Edited by mohanboddu

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.