On Fri, Aug 04, 2023 at 11:42:07AM +0100, Adam Williamson wrote: > On Fri, 2023-08-04 at 12:16 +0200, Miro Hrončok wrote: > > Hello folks, > > > > With the retirement of modularity, the modular dnf repositories for Fedora 39 > > no longer exist. However, this will introduce a problem during upgrades. When > > users try to upgrade from previous Fedora releases with fedora-repos-modular > > installed, they will hit fatal errors that will probably look like this: > > > > Errors during downloading metadata for repository 'fedora-modular': > > - Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > > (IP: ...) > > - Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > > (IP: ...) > > - Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > > (IP: ...) > > Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare > > internal mirrorlist: Status code: 404 for > > https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x86_64 > > (IP: ...) > > > > Or: > > > > Error: Failed to download metadata for repository 'fedora-modular': Cannot > > download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried > > > > (The actual error might differ depending on the exact state of the removal of > > the modular repos and their mirrorlist etc.) > > > > > > This is caused by the combination of the following facts: > > > > - the modular repo configuration in Fedora 37/38 has skip_if_unavailable=False > > - when the releasever is set to 39, the URLs of the repos give error 404 > > > > This is a big deal, because even users who don't use modularity at all (but > > have not uninstalled fedora-repos-modular) will not be able to upgrade to > > Fedora 39+ without reaching for help. > > > > Adam outlined 3 options to solve this problem in the bugzilla where he reported > > this: https://bugzilla.redhat.com/2228827 > > So an update to this, thanks to Miro for double-checking me: I had > forgotten that the openQA tests edit the dnf config to point to the > compose tree (in order to make sure we're testing the right thing - > there's an ordering problem if we just test the actual 'rawhide' > location on the mirror system, it might not have been synced by the > time the tests run). > > It looks like the public 'rawhide' location *does* still have a Modular > tree: > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/ > > but there's still a problem there, because...it's now just stale data. > That is the Modular tree from the 20230802.n.0 compose, and unless > someone does something about it, it always *will* be. Keeping the last > set of modular repos frozen in amber forever doesn't seem like the best > permanent situation :) Do we still have the problem where dnf will preferrentially pick content from a modular repo, even if it has older NEVR than the same package name in a non-modular repo ? IOW, would the existance of this stale modular content, prevent the upgrade tools from correctly bringing in content from the new release ? With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
