On Tue, Jul 7, 2020 at 5:04 AM Michael Schroeder <mls@suse.de> wrote:
On Tue, Jul 07, 2020 at 10:09:52AM +0200, Dan Čermák wrote:
(the following is my personal opinion/view)
Carson Black <uhhadd@gmail.com> writes:
Lately, I've become somewhat displeased by a lot of shortcomings of the libzypp stack in regards to how it serves openSUSE.
In condensed list form, my complaints are: - zypp using external binaries for tasks (rpm, repo2solv) causes updates that change those binaries to be be particularly unstable
Especially zypper subprocessing to call rpm is downright dangerous and caused a few issues when the database format of rpmdb changes (does not happen often, but we've had a recent one from BDB to NDB).
Ooh, be careful with that argument. Database format changes are not really supported by rpm/dnf at all. It took me quite some time to get it in a somewhat working state, but the pull request was never merged upstream.
[snip]
What are you talking about? Database format changes are supported just fine for more than a year. We've gone through this exercise in Fedora long before pulling the trigger on switching to SQLite for the rpmdb. In fact, I was waiting longer to have Zypper prepared in Fedora for it than DNF on openSUSE. Yes, some optimizations were broken because they assumed BDB file locations, but those were ripped out entirely. The version that is shipped in Leap 15.2 has those patched to work, even though they aren't needed. For openSUSE Tumbleweed, I've just made SRs to update the stack to the latest version, which does not require my patch.
Well, and then there's the elephant in the room: dnf is a Fedora (and thus a RedHat) product, while zypper is SUSE's child. Just because of that it's going to be a rocky road and it will probably take ages or be downright impossible to push dnf as the default to SLE (zypper has a lot of SLE specific handling, for example packagehub integration).
There's another elephant: dnf is currently getting completely rewritten. You shouldn't even think about changing to it unless that has been completed.
This is probably the right time to have that discussion so we can have openSUSE-specific gaps factored into the upstream development. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org