On 8. 4. 2015 at 14:44:25, Michal Schmidt wrote: > On 04/08/2015 08:41 AM, Jan Zelený wrote: > > On 7. 4. 2015 at 17:53:42, Ralf Corsepius wrote: > >> On 04/07/2015 05:07 PM, Kevin Fenzi wrote: > >>> dnf's default behavior is like yum with --skip-broken already. > >> > >> WHAT? > >> > >> --skip-broken is a band-aid to work around packaging mistakes and bugs > >> and NOT be the default. > >> > >> IMO, this kind of behavior is not helpful and therefore should be > >> reverted. > > > > This behavior is actually helpful, as it doesn't bother users with a bunch > > of broken deps messages they usually don't fully understand (check out > > how many of these bugs were filed against yum over the years). > > > > Putting the opinion of myself and the dnf team aside, I'd like to point > > out > > that the information you want is still available - dnf check-update will > > show you all the updates, even those that have broken deps. Running this > > command right after dnf upgrade will list you those that could not be > > installed. > Would it please be possible for "dnf update" to print this information > automatically? > E.g. apt-get can say "The following packages have been kept back: ..." > > dnf could report it like in this mockup: > ... > Dependencies resolved. > ======================================================================== > Package Arch Version Repository Size > ======================================================================== > Upgrading: > emacs x86_64 1:24.4-6.fc21 updates-testing 3.0 M > emacs-common x86_64 1:24.4-6.fc21 updates-testing 37 M > emacs-filesystem noarch 1:24.4-6.fc21 updates-testing 64 k > Skipping for dependency reasons: > firefox x86_64 37.0.1-1.fc21 updates-testing 69 M > > Transaction Summary > ======================================================================== > Upgrade 3 Packages > Skip 1 Package > > Total download size: ... > Is this ok [y/N]: > > Thanks, > Michal
Please open an RFE, the dnf devel team is tracking everything in bugzilla, including priorities. Don't forget to describe the use case ... Thanks Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
