Am 13.08.20 um 01:25 schrieb Neal Gompa:
On Wed, Aug 12, 2020 at 6:54 PM Aaron Puchert <aaronpuchert@alice-dsl.net> wrote:
Am 12.08.20 um 17:13 schrieb Neal Gompa:
No offering of solutions if there are dependency problems (dnf just exits)
[...]
I'd be interested in understanding what makes that feature compelling, given that every time I've had to use it, it doesn't work
That's not my experience. I've had a few cases where conflicts were getting too big and I had to abort, but in most cases one of the solutions was what I wanted and worked fine.
Why is it compelling? Sometimes there are genuine conflicts, and you don't want to remove packages manually before installing a new one, and this allows you to do installation and removal in one transaction. Quite possible that the manual removal wasn't enough, and you've got more conflicts, and then you decide that you can't go further and the removal was pointless. If you let the solver figure out the entire thing at once, you avoid that painful do-while loop with rollback.
This is still possible with DNF, it just doesn't do it interactively.
Then it's not a remotely comparable solution, sorry.
It will just fail and print out all the solver errors at once. You can use all those errors to adjust the transaction accordingly.
Yes, but this I can also do with plain rpm if i really want to hurt myself ;-)
You can also tell DNF to attempt to remove problematic packages all at once and attempt to resolve the transaction accordingly with "--allowerasing"
That's unfortunately never the solution that would seem useful or sensible to me (at least I cannot imagine it being useful).
[...] or leads to a broken system...
That would be strange, because requirements are still checked.
The point of this is to let you *ignore* dependencies and explicitly break them.
Well yes. "ignore" is probably an option that should be protected by an extra "i accept the risk" (uw-imap-style) confirmation prompt. It's for experts.
It was actually an early design goal that DNF does *not* include this functionality because people often used it to subtly break their systems with less-than-obvious ill effects.
I absolutely demand the right to shoot myself in the foot! ;-)
Maybe it's worth revisiting this, but I'm not sure it is...
I've seen people run into strange issues when they added repos from different distributions, such as Tumbleweed repos on a Leap system, and then often dependencies don't fit. Otherwise I've not seen conflict resolution break anything, if anything the conflicts got out of hand and I had to abort.
I have seen this happen quite often while maintaining OBS servers. :(
I do not remember this happening to me. Actually the zypper proposed resolutions on dependency problems being 99% useful versus the yast2 (pre-libsolv/zypper!!) proposed resolutions on dependency problems being 99% useless was *the* single selling point of zypper (actually of the satsolver) 15(?) years back. Probably dnf does provide the same useful resolution options (as everyone uses the satsolver nowadays), but being unable to apply them interactively feels like a HUGE step backwards to me. Now I'm happy I did not join the dnf train yet, it would have been a total waste of time for me: strolchi:~ # ls -1 /etc/zypp/repos.d|wc -l 18 => you get conflicts you have to resolve once in a while with that many repos. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org