https://bugzilla.redhat.com/show_bug.cgi?id=1762445 --- Comment #5 from Petr Pisar <ppisar@xxxxxxxxxx> --- (In reply to John Florian from comment #4) > I'm not sure I follow the whole [d] or [e] thing. Yours has a mix of [d] > and no [d]. Mine looks the same from what I can tell: > > $ dnf module list | grep '^perl\s' > perl 5.24 minimal, default > Practical Extraction and Report Language > perl 5.26 minimal, default [d] > Practical Extraction and Report Language > perl 5.26 minimal, default [d] > Practical Extraction and Report Language > perl 5.28 minimal, default [d] > Practical Extraction and Report Language > perl 5.30 common, minimal, default [d] > Practical Extraction and Report Language > That's fine. The [d] you can see is for a profile. E.g. perl:5.24 has two profiles "minimal" and "default". And none of the profiles is default. perl:5.26 has the same profiles, but "default" profile is default. What I was interested was [d] or [e] at a stream, compare with a "skim" module: # dnf --quiet module list skim Fedora Modular 29 - x86_64 - Updates Name Stream Profiles Summary skim rolling [d] default [d] Fuzzy Finder in Rust Fedora Modular 29 - x86_64 - Test Updates Name Stream Profiles Summary skim rolling [d] default [d] Fuzzy Finder in Rust Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled > And per your 2nd comment, I guess this is relevant: > > $ dnf module list | grep '^perl-bootstrap\s' > perl-bootstrap 5.24 > Perl bootstrap module for bootrapping Perl module > perl-bootstrap 5.26 > Perl bootstrap module for bootrapping Perl module > > Here I have no [d], so is that the problem? > That's as it should look like. No problem. > > I suspect that you either enabled 5.26 stream by an accident, or set > > module_hotfixes YUM repository configuration variable > > Those seem quite unlikely -- I manage everything with puppet and only this > one host is affected. > So do you have more hosts with the same configuration and only one of them manifests this bug? > > You can locate a repository the offending packages comes from with "dnf info > > perl-HTTP-Tiny" commnd and then check the appropriate modular metadata in > > /var/cache/dnf/*/repodata/*modules.yaml.gz whether the package is listed > > under data/artifacts/rpms YAML node. > > Hmmm... the query reports "From repo : local-fedora" which is my config > to a local mirror. But I can't chase that further because I see no such > *modules.yaml.gz for this repo. Do you I understand correctly, that local-fedora repository contains the perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch.rpm package, but does not have any modular metadata? That could be the cause. By default DNF considers all packages as a non-modular and only those listed in modular metadata as belonging to a module are handled as modular. If a module is active (i.e. enabled or default and not disabled), all packages from that module mask all other same-named packages (even non-modular one). If a module is not active, the packages of that module are not visible and only non-modular packages are considered. I assume that "dnf info perl-HTTP-Tiny" shows two packages for you: perl-HTTP-Tiny-0.076-1.fc29 and perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71. And because "module_2073+eebc5b71" is lexicographically higher than "fc29", DNF wants to upgrade perl-HTTP-Tiny to perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71. > Here's all of them: > > $ sudo find /var/cache/dnf -name '*modules.yaml.gz' > /var/cache/dnf/fedora-modular-454f0a18da8ca968/repodata/ > 9264d8d10ad5a5def81c888fb16bd7ce6b063a259a03af6eac2953f263078527-modules. > yaml.gz > /var/cache/dnf/updates-modular-fb00c2f37a3d46d7/tmpdir.vUVR7v/repodata/ > 31aee6cab351765d685156ff1f8a3d1b09caaa525bbf5e78c0942289d1964a05-modules. > yaml.gz > /var/cache/dnf/updates-modular-fb00c2f37a3d46d7/repodata/ > f472f4b1daad95a6583d847e8454567f586b32b12f6c38d69d8873ec9018b02b-modules. > yaml.gz > Technically DNF somehow merges modular metadata from all repositories, thus DNF should know that the problematic package is modular by getting the metadata from fedora-modular repository. But it's possible there is some bug about the merging in DNF of some of the underlying libraries. I tested my hypothesis by adding the package into a new repository without modular medata and DNF recognized the package as a modular. > So maybe my mirror is bad, but then that seems easily disproved by ignoring > my mirror (and private repo) to use stock Fedora repos: > > $ sudo dnf upgrade --disablerepo 'local-*' --disablerepo doubledog > No read/execute access in current directory, moving to / > Last metadata expiration check: 0:00:46 ago on Fri 01 Nov 2019 09:48:43 AM > EDT. > Dependencies resolved. > > Problem: package perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch > requires perl(:MODULE_COMPAT_5.26.2), but none of the providers can be > installed How's it possible? If you disable local-fedora repository, the perl-HTTP-Tiny-0.076-1.module_2073+eebc5b71.noarch should not be available because you said it comes from local-fedora repository. Where does "dnf --disablerepo 'local-*' info perl-HTTP-Tiny" find the package? Provided you do not use any modules, you could disable all modular repositories (fedora-modular, updates-modular, updates-testing-modular) and try it again if it helps? Also try deleting all files in /var/cashe/dnf. Maybe the cache is broken. At least I saw a spurious tmpdir.vUVR7v subdirectory there. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ perl-devel mailing list -- perl-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to perl-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/perl-devel@xxxxxxxxxxxxxxxxxxxxxxx
