On Tue, Jul 7, 2020 at 10:09, Dan Čermák wrote:

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).

Looking at SUSE support articles, Package Hub stuff is added with YaST and SUSEConnect, so zypp/er don't really have much to do with that Kinda related There were some plans to make an OBS plugin to make it easier to interact with OBS, but that was kinda abandoned, since OBS api requires authentication for every single action. https://github.com/rpm-software-management/dnf-plugins-extras/issues/64 Integrations like that aren't too hard to do, as long as there is an api of some kind LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jul 7, 2020 at 10:44, Dan Čermák wrote:

This is probably not going to get any simpler given the recent DOS "attacks" (not sure if they were attacks, but OBS' public routes got hammered by web crawlers), see https://github.com/openSUSE/open-build-service/issues/9876

It's probably all the people using HTML instead of the API because it doesn't require authentication LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2020-07-07 13:42, Stefan Seyfried wrote:

Am 07.07.20 um 10:53 schrieb Stasiek Michalski:

...

On Tue, Jul 7, 2020 at 10:44, Dan Čermák wrote:

...

This is probably not going to get any simpler given the recent DOS "attacks" (not sure if they were attacks, but OBS' public routes got hammered by web crawlers), see https://github.com/openSUSE/open-build-service/issues/9876

It's probably all the people using HTML instead of the API because it doesn't require authentication

At least stable released OBS versions (no idea what is running on build.o.o) do not need authentication for most stuff, just go the /public route:

And because "/public/" does not look much different from "/", I had already filed a bug related to that :-/ https://github.com/openSUSE/open-build-service/issues/9880

seife:~> curl https://build.opensuse.org/build/home:seife <status code="anonymous_user"> <summary>Anonymous user is not allowed here - please login</summary> </status> seife:~> curl https://build.opensuse.org/public/build/home:seife <directory> <entry name="openSUSE_Factory"/> <entry name="SLE_11_SP1"/> <entry name="SLE_10SP3"/> <entry name="Fedora_24"/> </directory> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 07.07.20 um 13:51 schrieb Dan Čermák:

As far as I know nothing under /public is part of the official & guaranteed API (ironically one tends to refer to this as the *public* API), so code relying on these routes can break at any time. My experience with OBS interfaces is "everything can break any time and will not necessarily be fixed, because it was broken on purpose". And "backporting stuff to stable releases is a rare event, because OBS developers only run unstable code anyway".

Not a pleasant thing to use, I agree. The OBS developer community's attitude has improved (depends on who gets to process your github issue) but still the experience is -- ahem -- "interesting", especially compared to friendly communities like, for example, kiwi, but no real alternatives to OBS exist for my use case. So my way of interfacing with OBS is "use what's available, and when they kill it, just look for an alternative, or hack some replacement in" ;-) -- 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

On Wed, Jul 8, 2020 at 16:15, Adrian Schröter wrote:

IMHO we a very good job in keeping a 15 years old api compatible and only extend it. There are not many doing that for that period of time...

I assume that's why most APIs have a version number in the URL, because we assume nothing is forever, and OBS is the proof of that ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jul 7, 2020 at 4:45 AM Dan Čermák wrote:

Stasiek Michalski writes:

...

On Tue, Jul 7, 2020 at 10:09, Dan Čermák wrote:

...

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).

Looking at SUSE support articles, Package Hub stuff is added with YaST and SUSEConnect, so zypp/er don't really have much to do with that

Kinda related There were some plans to make an OBS plugin to make it easier to interact with OBS, but that was kinda abandoned, since OBS api requires authentication for every single action. https://github.com/rpm-software-management/dnf-plugins-extras/issues/64

This is probably not going to get any simpler given the recent DOS "attacks" (not sure if they were attacks, but OBS' public routes got hammered by web crawlers), see https://github.com/openSUSE/open-build-service/issues/9876

...

Integrations like that aren't too hard to do, as long as there is an api of some kind

OBS has a pretty extensive API, but unfortunately (in this case) all of it requires authentication. However, I don't really see a reason why an interested user couldn't create an authentication token and put it into a config file? The UX wouldn't be as great as with the copr plugin, but better than nothing?

The problem is that OBS has no API token concept, so I can't even do that. I *could* write the plugin to use the ~/.config/oscrc that exists on disk, though. If I can get some time for this again, I may implement a "blind" plugin with obs:// URIs and add configuration for mapping obs:// URIs to download URLs. It's not great, but at least it's better than nothing, and essentially makes it the same as zypper's handling of obs:// URIs for adding OBS repos. -- 真実はいつも一つ！/ 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

On Tue, Jul 7, 2020 at 5:04 AM Michael Schroeder wrote:

On Tue, Jul 07, 2020 at 10:09:52AM +0200, Dan Čermák wrote:

...

(the following is my personal opinion/view)

Carson Black 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

On Tue, Jul 07, 2020 at 10:52:31AM +0200, Dan Čermák wrote:

Jan Engelhardt writes:

...

On Tuesday 2020-07-07 05:45, Carson Black wrote:

...

Lately, I've become somewhat displeased by a lot of shortcomings of the libzypp stack in regards to how it serves openSUSE.[...] From what I can tell, the only things that need any further integration work besides just switching out the package manager would be[...]

* "product" support * downgrade support (zypper dup)

Downgrades are supported via `dnf distro-sync --allowerasing` (allowerasing is necessary sometimes when packages get dropped from Factory).

Be careful with allowerasing, it can completly wreck your system. The difference between dnf and libzypp is actually the "keeporphans" option: dnf sets it to true telling libsolv that it must keep all orphaned packages (packages that are not backed by a repository) installed. Cheers, Michael. -- Michael Schroeder SUSE Software Solutions Germany GmbH mls@suse.de GF: Felix Imendoerffer HRB 36809, AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2020-07-07 12:33, Neal Gompa wrote:

...

...

...

* downgrade support (zypper dup)

Downgrades are supported via `dnf distro-sync --allowerasing`

The difference between dnf and libzypp is actually the "keeporphans" option

Yes, so if you want to remove orphans, you can use "dnf autoremove". Note that this relies on the DNF history database[..]

Ah yeah, speaking of it: weakremover() support in zypper. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2020-07-07 05:45, Carson Black wrote:

Lately, I've become somewhat displeased by a lot of shortcomings of the libzypp stack in regards to how it serves openSUSE.[...] From what I can tell, the only things that need any further integration work besides just switching out the package manager would be[...]

Be careful with this argument: I have spent time with both (used to work for Red Hat), and I have to say I prefer zypper hugely, both for its speed and features. Some things are not so easy (I cannot do `sudo zypper in /usr/bin/name`), but some things are better. And from what I know about dnf, than it was mostly rather poor rewrite of libzypp, which was so bad, they are rewriting it again. I don't think we should attach ourselves to something which has been effectively abandoned. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Never ascribe to malice that which is adequately explained by stupidity. -- Napoleon Bonaparte (or many other people to whom this quote is ascribed) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday 2020-07-07 13:55, Dan Čermák wrote:

Well, with all the talk about how great dnf is, I shall try it (on openSUSE).

I am honestly curious here, which parts of zypper do you miss from dnf?

* parallel download of metadata seems to be not happening * `dnf update` is much more verbose, akin to `zypper -v up` and I do not know of a way to make dnf give terse output. 14:07 a4:~ # zypper up The following item is locked and will not be changed by any action: Installed: wicked-service The following 42 package updates will NOT be installed: binutils binutils-gold coreutils coreutils-doc cpp cpp10 cpp9 cross-sparc64-binutils gcc gcc-PIE gcc-c++ gcc-info gcc10 gcc10-c++ gcc10-debugsource gcc10-info gcc9 gcc9-c++ gdb gsoap-devel libasan5 libasan6 libatomic1 libctf-nobfd0 libctf0 libgcc_s1 libgcc_s1-debuginfo libgfortran4 libgomp1 libitm1 liblsan0 libobjc4 libpcap1 libquadmath0 libstdc++-devel libstdc++6 libstdc++6-debuginfo libstdc++6-devel-gcc10 libstdc++6-devel-gcc9 libtsan0 libubsan1 wicked-service The following 3 packages are going to be upgraded: libstdc++6-pp-gcc11 mingw64-libwinpthread1 mingw64-winpthreads-devel 3 packages to upgrade. Overall download size: 162.9 KiB. Already cached: 0 B. No additional space will be used or freed after the operation. » dnf update ================================================================================ Package Arch Version Repo Size ================================================================================ Upgrading: binutils x86_64 2.34-386.1 gcc 5.8 M binutils-gold x86_64 2.34-386.1 gcc 1.3 M * dnf by default proposes vendor changes, zypper doesn't * dnf allows for vendor changes to sneak in: The "repo" column may tell me where the update is coming from, but does not tell me if that's gcc->gcc or tumbleweed->gcc. * dnf help | grep -i lock where is the package lock feature? * `dnf in --setopt=install_weak_deps=False blah` is quite a mouthful over `zypper in --no-r blah` * dnf is slower in some regard - e.g. single package install # time zypper in -y cdecl Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: cdecl 1 new package to install. Overall download size: 128.5 KiB. Already cached: 0 B. After the operation, additional 328.5 KiB will be used. Continue? [y/n/v/...? shows all options] (y): y Retrieving package cdecl-7.3-1.1.x86_64 (1/1), 128.5 KiB (328.5 KiB unpacked) Retrieving: cdecl-7.3-1.1.x86_64.rpm .....................................[done] Checking for file conflicts: .............................................[done] (1/1) Installing: cdecl-7.3-1.1.x86_64 ...................................[done] real 0m1.335s user 0m1.095s sys 0m0.203s # time dnf -y in cdecl Repository 'base' is missing name in configuration, using id. Repository 'debug' is missing name in configuration, using id. Repository 'src' is missing name in configuration, using id. Repository 'gcc' is missing name in configuration, using id. Repository 'kopano' is missing name in configuration, using id. Repository 'mingw' is missing name in configuration, using id. Repository 'jeng' is missing name in configuration, using id. Repository 'packman' is missing name in configuration, using id. Last metadata expiration check: 0:12:14 ago on Tue Jul 7 14:05:26 2020. Dependencies resolved. ================================================================================ Package Architecture Version Repository Size ================================================================================ Installing: cdecl x86_64 7.3-1.1 base 128 k Transaction Summary ================================================================================ Install 1 Package Total download size: 128 k Installed size: 328 k Downloading Packages: cdecl-7.3-1.1.x86_64.rpm 6.9 MB/s | 128 kB 00:00 -------------------------------------------------------------------------------- Total 6.6 MB/s | 128 kB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Installing : cdecl-7.3-1.1.x86_64 1/1 Verifying : cdecl-7.3-1.1.x86_64 1/1 Installed: cdecl-7.3-1.1.x86_64 Complete! real 0m2.653s user 0m2.484s sys 0m0.125s That's all I have for the time being. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 7 Jul 2020 19:25:44 +0800, Maurizio Galli wrote:

Hello Carson,

On Tue, Jul 7, 2020 at 11:46 AM Carson Black wrote:

...

Any thoughts/objections regarding the possibility of replacing the libzypp stack in openSUSE with the libdnf stack?

-- Carson Black [ jan Pontajosi, Jan Blackquill ]

Mine is a feedback as a Tumbleweed user, and switching to dnf was very good for me:

1) Parallel download is a blessing because mirrors in China aren't always very fast. 2) I don't need to taboo packages I don't want to reinstall after each dup anymore because from what I can tell dnf remembers them unlike zypper. 3) Aliases already in place for dnf to mimic zypper are for the most part enough for my user case. Plus i'm discovering additional dnf features that zypper is missing such as removing orphan packages.

Is there a list of "matching" options yet? zypper clean --all dnf clean all zypper dup dnf upgrade zypper in dnf install zypper lr dnf repolist zypper ls dnf repolist zypper lu dnf check-update --cacheonly zypper lp dnf updateinfo --cacheonly --security zypper patch dnf update-minimal --cacheonly --security zypper ref dnf makecache zypper rm dnf erase zypper se dnf search zypper up dnf update Oh, and every time I need to use dnf (which I remember as acronym for Did Not Finish) I curse the fact that it doesn't know abbreviations like zypper does. I already entered "dnf se pattern" and "dnf in foo" a zillion times on CentOS. I also dislike the always automatic refresh that yum and dnf do, I want to refresh once and than set --cacheonly for all subsequent commands. (see below for zypper) And "dnf clean all" mostoften *also* requires a "rm -rf /var/cache/yum" Having to use both on many systems on an almost daily basis, I prefer zypper over dnf by far.

I don't have the experience to go in depth, but as a user the above was enough to make dnf a permanent switch. Best Regards,

I have a "y2" command that "bundles" the YaST2 and zypper commands to a default that matches my daily work, and it has above list builtin, so I can use "y2" on CentOS too for the simple stuff. "y2" also adds "--no-refresh" to lu/lp/patch/up/ and dup and -l to patch/up/dup. # y2 se libfoo now works everywhere (on the systems where I put y2 in my bin/)

Maurizio

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jul 7, 2020 at 14:15, Stasiek Michalski wrote:

On Tue, Jul 7, 2020 at 14:09, H.Merijn Brand wrote: The refresh timer can be (and usually is) set in repo files. For Fedora repos I believe it's set to a couple of days, for Tumbleweed it would probably be daily for the sake of dupping. For Leap couple of days should be more than enough.

I looked into the documentation, and that reminded me that since zypp has the awful habit of rewriting every repo file it reads, if you use both at the same time, you will have your metadata refreshed in dnf after every time you used zypp/yast. Yes, it's the worst. Just use dnf ;) LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Jul 7, 2020 at 8:10 PM H.Merijn Brand wrote:

Is there a list of "matching" options yet?

zypper clean --all dnf clean all zypper dup dnf upgrade zypper in dnf install zypper lr dnf repolist zypper ls dnf repolist zypper lu dnf check-update --cacheonly zypper lp dnf updateinfo --cacheonly --security zypper patch dnf update-minimal --cacheonly --security zypper ref dnf makecache zypper rm dnf erase zypper se dnf search zypper up dnf update

On top of my head some of the similar commands are: zypper dup > dnf dup zypper in > dnf in zypper ref > dnf ref zypper se > dnf se zypper rm > dnf rm zypper up > dnf up I'm probably missing others. Best, Maurizio -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Jul 8, 2020 at 9:10 AM Bernhard M. Wiedemann wrote:

Am 07.07.20 um 14:09 schrieb H.Merijn Brand:

...

Is there a list of "matching" options yet?

zypper clean --all dnf clean all

https://wiki.archlinux.org/index.php/Pacman/Rosetta

That's a pretty good comparison, however I'll note that there is a "dnf shell" subcommand to give you interactive shell. :) -- 真実はいつも一つ！/ 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