
On Mon, 2020-12-14 at 07:58 -0500, Neal Gompa wrote:
DNF uses librpm to run the transaction the same way RPM would. That is, all the packages are collected and installed in a single transaction, so transfiletrigger works correctly. File triggers (especially transfiletriggers) are used extensively in Fedora, Mageia, and OpenMandriva (where DNF is used), so I know that it works pretty much perfectly.
Switching to DNF means the issue we have around transaction scriptlets goes away.
And others appear :) DNF is interesting - and I started playing with it a bit too. What boggles me most so far is that we cannot just mix-and-match zypper and dnf. As a user, I have to either opt to use one (and not use the other) or maintain both in good stading order. What I mean, especially, is that the repo files/definitions are not being shared. If I was to switch to dnf, then all the yast tools might get the wrong info, as they are using the libzypp/zypper backend - whereas aas user I interact with dnf and use different repositories. yaiks. compare to zypper dup, dnf upgrade (somehow I assumed this would be the right thing for TW) does not offer downgrades. And the third thing I found while just running it in first trials that it wanted to install 'some -lang' packages (very few). on zypp, I have *-lang locked, so I am clear not to have any installed. as dnf does not use my locks (I guess) I was quite surprised that it only wanted to install like 3 -lang packages - of course honoring my zypp lock would be even better) This mail is not meant to dimish the work done in DNF - it seems to do what it advertises, something a bit better than zypper, somethings different, something possibly worse. Advertising it as 'the solution to all problems' is a bit premature though.