The One Problem I Have So Far With Fedora's DNF Package Manager

[bug77]

It didn't use to be invalid, but now it is. With the yum command redirecting to dnf, what I'm arguing is that it's now breaking existing scripts -- even if the rest of the yum command/transaction is completely fine and normal -- rather than (in my opinion) just issuing a warning or silently ignoring that argument.

I know what you mean, but since there's no yum, it would have to be dnf that ignores a non-existing option. And that would make dnf non-compliant. I'm not saying it's not annoying, I'm just saying the need to keep dnf compliant is understandable, since dnf is supposed to be the future while yum goes the way of the dodo.
Plus, as mentioned above, one can always use update-alternatives and point yum as needed.

[Ericg]

Michael
Wait, I can seriously tag users now!? That's awesome. Copy-pasting from other thread cause I just realized it'll probably get buried

Hey Michael,

Fedora 21, Firefox 37.0.2. If I browse to the forums via HTTPS (whether by manually adding https://, or running HTTPS Everywhere) i can't post. Like the "Reply" section doesn't work, doesn't accept input, doesn't have its little "Write something..." message

[Michael]

Three methods to fix broke yum scripts, for anyone suffering from similar issues:

1) Actually fix the script in whatever way needs be.
2) swap "yum" to "yum-deprecated"
3) if scripts can't be updated, or inconvenient, alias yum to yum-deprecated.

I already updated my upstream scripts, albeit anyone using old versions of PTS on Fedora will then suddenly find their external dependency handling borked.

[Ericg]

DNF's builddep plugin i able to automatically guess at dependencies unlike YUM, it now requires a SPEC to be provided which is extremely annoying
DNF still doesn't have an equivalent to YUM's fastestmirror plugin AFAIK
I've also had issues while trying to mass uninstall packages using wildcards with DNF (e.g. dnf remove wine-*)

The fact that there's no option to force dnf builddep to guess without having to provide a SPEC is a deal breaker for me. I don't care if it wasn't always accurate, it was still extremely useful.

There's a note about fastest mirror in the link. On mobile so can't really quote it. Just ctrl-f "fastestmirror"

[Ericg]

It didn't use to be invalid, but now it is. With the yum command redirecting to dnf, what I'm arguing is that it's now breaking existing scripts -- even if the rest of the yum command/transaction is completely fine and normal -- rather than (in my opinion) just issuing a warning or silently ignoring that argument.

Three methods to fix broke yum scripts, for anyone suffering from similar issues:

1) Actually fix the script in whatever way needs be.
2) swap "yum" to "yum-deprecated"
3) if scripts can't be updated, or inconvenient, alias yum to yum-deprecated.

[Ouroboros]

DNF's builddep plugin isn't able to automatically guess at dependencies unlike YUM, it now requires a SPEC to be provided which is extremely annoying
DNF still doesn't have an equivalent to YUM's fastestmirror plugin AFAIK
I've also had issues while trying to mass uninstall packages using wildcards with DNF (e.g. dnf remove wine-*)

The fact that there's no option to force dnf builddep to guess without having to provide a SPEC is a deal breaker for me. I don't care if it wasn't always accurate, it was still extremely useful.

[Michael]

$ ls -z
ls: invalid option -- 'z'

Looks like standard behaviour to err on invalid switches.

It didn't use to be invalid, but now it is. With the yum command redirecting to dnf, what I'm arguing is that it's now breaking existing scripts -- even if the rest of the yum command/transaction is completely fine and normal -- rather than (in my opinion) just issuing a warning or silently ignoring that argument.

[bug77]

$ ls -z
ls: invalid option -- 'z'

Looks like standard behaviour to err on invalid switches.

[finalzone]

--skip-broken semantics is built-in in DNF by default. See

http://dnf.readthedocs.org/en/latest/cli_vs_yum.html

[phoronix]

Phoronix: The One Problem I Have So Far With Fedora's DNF Package Manager

DNF 1.0 was released this week ahead of the Fedora 22 debut later this month where it will replace Yum by default as the package manager. In my testing of DNF on Fedora 22 and earlier releases, it's worked out quite well, but there's one issue that still nags me about Dandified Yum...

http://www.phoronix.com/scan.php?page=news_item&px=DNF-One-Problem-So-Far