Description of problem: dnf doesn't have --skip-broken nor -x options and it makes it unusable in situations like in current f18 repos, where there is newer version of dnf available but it depends on not-yet-available hawkey - and this conflict blocks whole operation of dnf. Being able to skip gracefully would be a great help here. Version-Release number of selected component (if applicable): dnf-0.2.13-1.gitda60a96.fc18.noarch hawkey-0.2.12-2.git7fa7aa9.fc18.x86_64 How reproducible: always Steps to Reproduce: 1. have an update available to package1 that depends on unavailable (version of) package 2. perform 'dnf update' 3. Actual results: dnf fails completely with dependency error: Error: nothing provides python-hawkey >= 0.3.0 needed by dnf-0.2.14-2.git4831982.fc18.noarch Expected results: dnf tries to find workable solution to the task (an equivalent of yum --skip-broken) Additional info: [root@localhost ~]# yum -x '*i686' info hawkey dnf Loaded plugins: auto-update-debuginfo, downloadonly, fastestmirror, langpacks, presto, refresh-packagekit Determining fastest mirrors * fedora: ftp.upjs.sk * fedora-debuginfo: ftp.upjs.sk * updates: ftp.upjs.sk * updates-debuginfo: ftp.upjs.sk Installed Packages Name : dnf Arch : noarch Version : 0.2.13 Release : 1.gitda60a96.fc18 Size : 2.8 M Repo : installed From repo : fedora Summary : Package manager forked from Yum, using libsolv as a dependency resolver URL : https://github.com/akozumpl/dnf License : GPLv2+ and GPLv2 and GPL Description : Package manager forked from Yum, using libsolv as a dependency resolver. Name : hawkey Arch : x86_64 Version : 0.2.12 Release : 2.git7fa7aa9.fc18 Size : 92 k Repo : installed From repo : fedora Summary : Library providing simplified C and Python API to libsolv URL : https://github.com/akozumpl/hawkey License : LGPLv2+ Description : A Library providing simplified C and Python API to libsolv. Available Packages Name : dnf Arch : noarch Version : 0.2.14 Release : 2.git4831982.fc18 Size : 542 k Repo : fedora/18/x86_64 Summary : Package manager forked from Yum, using libsolv as a dependency resolver URL : https://github.com/akozumpl/dnf License : GPLv2+ and GPLv2 and GPL Description : Package manager forked from Yum, using libsolv as a dependency resolver.
Hi David, thanks for the report. The fix is implemented by 533b377. DNF drops --skip-broken completely in favor of what is suggested by this bug. The new semantics is documented here: http://akozumpl.github.com/dnf/command_ref.html#update-command Some rationale about removing the Yum --skip-broken switch: file:///home/akozumpl/dnf/build/doc/cli_vs_yum.html#no-skip-broken
> Some rationale about removing the Yum --skip-broken switch: > > file:///home/akozumpl/dnf/build/doc/cli_vs_yum.html#no-skip-broken That should be http://akozumpl.github.com/dnf/cli_vs_yum.html#no-skip-broken
I disagree with #1. Today I run: # dnf upgrade Setting up Update Process Resolving Dependencies --> Starting dependency resolution --> Finished dependency resolution Nothing to do # And I then follow with yum upgrade (because still testing dnf vs. yum) I got: ... long list of conflicts: Error: Package: culmus-fonts-compat-0.121-3.fc18.noarch (@fedora) Requires: culmus-keteryg-fonts = 0.121-3.fc18 Removing: culmus-keteryg-fonts-0.121-3.fc18.noarch (@fedora) culmus-keteryg-fonts = 0.121-3.fc18 Updated By: culmus-keteryg-fonts-0.121-4.fc18.noarch (updates-testing) culmus-keteryg-fonts = 0.121-4.fc18 Error: Package: culmus-fonts-compat-0.121-3.fc18.noarch (@fedora) Requires: culmus-miriam-clm-fonts = 0.121-3.fc18 Removing: culmus-miriam-clm-fonts-0.121-3.fc18.noarch (@fedora) culmus-miriam-clm-fonts = 0.121-3.fc18 Updated By: culmus-miriam-clm-fonts-0.121-4.fc18.noarch (updates-testing) culmus-miriam-clm-fonts = 0.121-4.fc18 There are obviously bug in spec of those packages (incorrect provides/obsoletes). And if I would use only dnf, I would *never* know. Those packages would be never tested. It would hit 7 days quarantine in bodhi and get pushed to stable. Maintainer would think he done his job, users will never see those new packages. There will be no reports and no progress. And those conflicting packages does not necessary come from distribution. It may be user private package, which create conflic with some Fedora package and user will be suddenly blocked from updates (and security updates) and he will never know about it as he would think he has up to date system. Only because dnf say "Nothing to do". I would say *some* report about unresolvable packages is must. Something like --> Starting dependency resolution --> Finished dependency resolution --> 5 Packages unresolvable Nothing to do And if you specify -vv or --show-me-those-dammmned-conficts it would show detailed output of those conflicts.
(In reply to comment #3) ... > There are obviously bug in spec of those packages (incorrect > provides/obsoletes). > And if I would use only dnf, I would *never* know. Those packages would be > never tested. It would hit 7 days quarantine in bodhi and get pushed to > stable. > Maintainer would think he done his job, users will never see those new > packages. There will be no reports and no progress. > This IMO indicates that Fedora project relies too much on users for stuff that it should check itself. Or if we do insist on leaving this on users, such conflict could be reported (semi-)automatically for conflicts that involve only packages from Fedora repos. > And those conflicting packages does not necessary come from distribution. It > may be user private package, which create conflic with some Fedora package > and user will be suddenly blocked from updates (and security updates) and he > will never know about it as he would think he has up to date system. Only > because dnf say "Nothing to do". > > I would say *some* report about unresolvable packages is must. Something like > --> Starting dependency resolution > --> Finished dependency resolution > --> 5 Packages unresolvable > Nothing to do > > And if you specify -vv or --show-me-those-dammmned-conficts it would show > detailed output of those conflicts. Similar output should be added to summary after successful transactions (Skipped (dependency problems): as has yum with --skip-broken) because few lines at the middle of the yum/dnf output can be overlooked way too easily.
Hello, I will think about a switch for listing the mentioned info (it is not as straightforward as it seems because the semantics of the plain 'update' operation is to 'update what you can', not 'update all where there is a higher version available'). In the meantime you can try 'dnf upgrade-to <package-version-release.arch>', to see what happens when you try to specifically update the package you are testing.
>This IMO indicates that Fedora project relies too much on users for stuff that it should check itself. Yes - We called that community driven project :) > Similar output should be added to summary after successful transactions (Skipped (dependency problems): as has yum with --skip-broken) because few lines at the middle of the yum/dnf output can be overlooked way too easily. +1
(In reply to comment #6) > > This IMO indicates that Fedora project relies too much on users for > > stuff that it should check itself. > > Yes - We called that community driven project :) Jokes aside, the packages workflow seems to rely on broken behaviour of yum (from POV of user any sane package manager) so once this is fixed, the gap has to be bridged. Based on Aleš's comment 5, it would mean code addition to current dnf so the question is if it isn't better to add the code to place where it fits better.
FWIW I opened bug 882211 to track this.