* meta package with "Requires: php-xmlreader" * "dnf upgrade" ignores it completly * do error messages * meta package not mentioned at all * dependency not installed * after manually install php-xmlreader suddenly the metapackage got installed with "dnf upgrade" the whole point of add "Requires:" to whatever package is a) update it and b) pull explicit dependencies and it's unacceptable that such basic operations silently don't work given how many years are gone since dnf replaced yum
Hello, from the bugreport it's not clear to me what exactly the problem is. I will probably need some additional information: - could you specify more precisely how to reproduce the issue? - can you post here the spec file of the meta package which doesn't work for you so I could try to reproduce the behaviour? - what are the versions of Fedora, dnf and libdnf used?
i maintain the metapackge below for years, there are for more Requires lines but that don't matter * yesterday i added the line "Requires: php-xmlreader" * updated the package * moved it to my own https repo * createrepo_c well, on the destination machine "dnf" said "Nothing to do" ciopied the metapackge manually and tried to install with "rpm -Uvh" which complaiend as excepted that "php-xmlreader" is required but missing, after "dnf install xml-reader" dnf later decied with a simple "dnf upgrade" that there is a new version of the metapackage and pulled it the job if dnf had been pull xml-reader when find the new metaüpakcage with the added dependency without manually fiddling around -------------------------------------------------------- [root@testserver:~]$ cat /rpmbuild/SPECS/rhsoft-workstation.spec Summary: meta-package for rhsoft workstation-packages Name: lounge-rhsoft-workstation Version: 30.0 Release: 2%{?dist} BuildArch: noarch URL: https://www.rhsoft.net/ License: GPLv2 Obsoletes: at Obsoletes: ed Obsoletes: lsb Obsoletes: redhat-lsb Obsoletes: redhat-lsb-core Obsoletes: redhat-lsb-cxx Obsoletes: redhat-lsb-desktop Obsoletes: redhat-lsb-languages Obsoletes: redhat-lsb-printing Obsoletes: redhat-lsb-submod-multimedia Obsoletes: redhat-lsb-submod-security Provides: at Provides: ed Provides: lsb Provides: redhat-lsb Provides: redhat-lsb-core Provides: redhat-lsb-cxx Provides: redhat-lsb-desktop Provides: redhat-lsb-languages Provides: redhat-lsb-printing Provides: redhat-lsb-submod-multimedia Provides: redhat-lsb-submod-security Requires: php-imap Requires: php-pcntl Requires: php-pecl-geoip Requires: php-pecl-imagick Requires: php-pecl-mailparse Requires: php-pecl-vld Requires: php-pecl-xdebug Requires: php-phar Requires: php-posix Requires: php-readline Requires: php-tokenizer Requires: php-xmlreader Requires: php-xmlwriter Requires: sddm %description meta-package for rhsoft workstation-packages %prep %build %install mkdir -p %{buildroot}%{_bindir} echo "#!/usr/bin/bash" > %{buildroot}%{_bindir}/lsb_release chmod 755 %{buildroot}%{_bindir}/lsb_release %files /usr/bin/lsb_release %changelog * Wed Oct 18 2017 Reindl Harald <harry> - add '/usr/bin/lsb_release' so that fucking google chrome installs * Sun Apr 29 2012 Reindl Harald <harry> - initial build
Isn't it possible, that you simply forgot to increment version/release of the metapackage after adding a new requirement? The other possibility is, that dnf used cached repository metadata. If this is the case, you can either run # dnf makecache to force refreshing the cache, or add --refresh option to the dnf upgrade command. See also https://dnf.readthedocs.io/en/latest/conf_ref.html#metadata-expire-label for setting the time interval, after which the repository metadata are considered expired.
* no it is NOT possible because %dist %dist .fc%fedora.%(echo $(/usr/bin/date +%Y%m%d)).rh.fc%fedora.%(echo $(/usr/bin/date +%Y%m%d)).rh * i already told you "rpm -Uvh" refused to upddate the package because of the missing php-xmlreader * i even explained you after manually install php-xmlreader dnf started to mention and install the updated metapackage * don't tell me about metadata when i do "rm -rf /var/cachednf/myrepo*" which has a timeout of 5 minutes to begin with when i tell you dnf was fucking too stupid to do it's job you can be sure it's fact
Well, you don't need to be rude. I just tried my best to understand and then reproduce your problem and even your last comment did not help much. If you are still able to reproduce the issue, can you please post here step by step instructions how to do it with all relevant data?
see the inital report without typo "do error messages" which should have been "no error messages" * meta package with "Requires: php-xmlreader" * "dnf upgrade" ignores it completly * no error messages * meta package not mentioned at all * dependency not installed * after manually install php-xmlreader suddenly the metapackage got installed with "dnf upgrade" wenn i told you that "dnf install php-xmlreader" manually followed by "dnf upgrade" updated the metapackage there is no point think about "maybe you forgot increase the version"
and what *really* annoys me is that DNF don't say anything useful for a lot of situations, that starts with pulling a dependency where yum clearly said which shit package requires libxyz.so.x and so pulls it leading in a dependency chain - that's how i learned over the years how and which packages are tied together and that was luckily before dnf, starting in 2019 i woulddn't know anything after two years because it's all burried and hidden when you skip/pull something echo out the reason, not uonly because it may help the user, it also makes qualified bugreports easier no matter if it affects DNF itself or a random update which suddenly pulls 100 MB deps and 100% sure with YUM the inital report would have shown the root cause because YXUM would have told it to me
What you are doing with the meta package (add a requirement, release a new version) is quite common task and generally DNF does not have any problem with it. Of course there might be a bug in the DNF which emerged in some specific circumstances. To find and resolve this bug I need more information, a reliable reproducer at the best.
you have basically the spec file in comment 2 look at the abosoletes / provides to avoid "at" and "qt3" and again: if dnf would have useful outputs as yum did i likely would have been able to write a qualified bugreport when it don't say anything but I know for sure it had to find a update for a package I built recently that's unhelpful for me and for you and that all to satisfy a user base which don't use a terminal application at all
I tried to reproduce this but without any success and we cannot do much without the reproducer. For now I'm closing the bug as insufficient data. Please feel free to re-open the bug if there is any new information or the problem gets reproducible.