On Mon, Jan 7, 2019 at 1:54 PM, Neal Gompa <ngompa13@gmail.com> wrote:

On Mon, Jan 7, 2019 at 3:18 AM <hellcp@opensuse.org> wrote:

...

Hi,

Since 2007 ZYpp has a backend for PackageKit, during openSUSE 11 discussions specification regrading notifying user about new upgrades was created. Instead of relying on existing tooling, developers decided to opt for newly created PackageKit to do it instead. That's how we got function that checks for upgrades based on product definition in /etc/product.d/. Obviously that's not a great system, considering the history of openSUSE, with switch to Leap, we can't expect ourselves to know what the next openSUSE will be early enough to put the correct definition of upgrades a year prior to next version coming out. After all, it's not just Leap that is an option during upgrades, there is also Tumbleweed which Leap can upgrade to.

Old specification: https://old-en.opensuse.org/Product_management/Code11/Upgrade Current code regarding upgrade checks in PackageKit ZYpp backend:

https://github.com/hughsie/PackageKit/blob/master/backends/zypp/pk-backend-z...

Now that Ludwig has been looking into using releasever in openSUSE repositories (at last, that has been supported by ZYpp for a very long time), we can have nice things, like easy upgrades, and much easier specifications regarding new versions of openSUSE consumable by third party applications, like ZYpp backend for PackageKit. Also wagon has been dead for a long time, would be nice to make it easier for users to upgrade easily (although `zypper dup --releasever 15.2` is quite easy, not UI enough for me).

ZYpp specification regarding repo variables: https://doc.opensuse.org/projects/libzypp/HEAD/zypp-repovars.html

There are at least 2 ways to approach that obviously, both very similar though. Let's call them Fedora way and old-modified for the sake of this mail.

Fedora uses their own plugin to Gnome Software to check for "collections" (read upgrades) in a spec they host on their server. That spec specifies what release is currently maintained, active, EOL, unstable, etc. When Gnome Software daemon is run, it checks that file for information regarding updates, downloads artwork for next release and displays nice banner in Gnome Software (or any app store using the same backend). This solution is visually stunning, but requires a bunch of software, which is not desirable. I think we could use that style of showing upgrades for users that do have Gnome Software based applications installed, but shouldn't be necessary to get notified about the next upgrade.

Fedora's spec: https://admin.fedoraproject.org/pkgdb/api/collections/ Gnome Software Fedora Collections code:

https://gitlab.gnome.org/GNOME/gnome-software/tree/master/plugins/fedora-pkg...

It is not necessarily true that "a bunch of software" is required for this. From GNOME Software's point of view, it's just requesting a blob to process. That can be static or dynamic. While Fedora's is dynamic, Mageia's is static and edited by humans. (Yes, Mageia doesn't have a g-s plugin yet, I'm working on it!)

The advantage of this approach is that if the availability of an upgrade needs to be disabled for whatever reason, you can kill it immediately. Also, you can have more than GNOME Software leverage that. Anything that could want to "listen" for openSUSE upgrades and either notify or trigger them can use the same end point.

Still much more software uses PK over GS ;) I understand the advantages, but this is the kind of design that should work pretty much everywhere, with the software that already exists (this is what being lazy is like :P).

...

Old-modified however would specify url of the same kind of file that is used for Fedora upgrades, but thanks to it being specified in /etc/product.d/, it would be usable by ZYpp backend for PackageKit, which would fetch whatever we decide to put into the file on the server. Similar file already exists in software-o-o, but for the purposes of generating different output in html resulting in distributions part of the site.

software-o-o definition:

https://github.com/openSUSE/software-o-o/blob/master/config/releases.yml

So product.d definition that would have looked like this in the past:

```xml <?xml version="1.0" encoding="UTF-8"?> <product schemeversion="0.0"> <vendor>Novell</vendor> <name>openSUSE</name> <version>11.0</version> ... <upgrades> <upgrade> <name>openSUSE_11.1</name> <summary>openSUSE 11.1</summary> <repository> http://download.opensuse.org/distribution/openSUSE/11.1 </repository> <notify>true</notify> <status>stable</status> </upgrade> <upgrade> <name>openSUSE_Factory</name> <summary>openSUSE Factory</summary> <repository>

http://download.opensuse.org/distribution/openSUSE/Factory </repository> <notify>false</notify> <status>unstable</status> </upgrade> </upgrades> ... </product> ```

would instead be:

```xml <?xml version="1.0" encoding="UTF-8"?> <product schemeversion="0.0"> <vendor>openSUSE Project</vendor> <name>openSUSE Leap</name> <version>16.0</version> ... <upgradespec> https://software.opensuse.org/distributions/productdef </upgradespec> ... </product> ``` (just an example, not a real url)

And the spec would be written in the same manner as Fedora's collections (but specify url for Tumbleweed repository, because it's not easily changable with current way we have $basename specified, that should be improved too most likely).

The problem with this approach is that a package has to be updated first before you'll get notified of a distribution upgrade. This is problematic for a number of reasons, because people sometimes only do distribution upgrades and don't frequently do regular updates. Or maybe they missed *that one update* that provided the definition.

Ideally, with either approach, you'd ship the repo files for the distribution in a package so that the content is static and set up with $releasever. In Fedora and Mageia, we have a system-repos package (Fedora's is fedora-repos, Mageia's is mageia-repos). These ship all the default repos for the distribution with their correct states (enabled, disabled, correct priorities, correct base paths, repo vars, etc.). Additional repos can be added as normal, but zypper/yast can be configured to make them somewhat differently from base repos (for example, a different default priority or something).

This eliminates all the current fiddling people have to do for doing system upgrades, and makes it as easy as "zypper dup --releasever=16.0", just as "dnf --releasever=29 distro-sync" would work on Fedora.

In a perfect world `zypper dup --basename tumbleweed --releasever ''` would be a valid command to upgrade to Tumbleweed from Leap :P Good ideas aside, obviously the best approach is static repos, the fact that priorities for all the repos are flat is certainly not a great design :P However I don't think that standard updates should be necessary in the whole process, but I get your point. The best way to approach updates like 42.3 -> 15.0 as it already happened would be to add relations between the distributions. In that case even if one day openSUSE Project splits Leap into two new distributions, release manager would have to take preference for default upgrade for users, but it's a small price to pay for flexability of that approach (even for other potential vendors).

...

A new specification of this kind will obviously requre some discussion, which I invite you to do. After some discussion I will consider the input and implement whatever comes out of it. Now I should get back to Artwork, where I belong.

I like you doing code things too. :)

I think just you, quality of code overall goes down immidiately ;)

...

Ah, and btw, PackageKit will soon be able to do dup for Tumbleweed: https://github.com/hughsie/PackageKit/pull/305 I expect that to be tested by openQA, it will make Tumbleweed easier to use for newbs :D

Yeah, it's nice to see the zypp backend get some love.

...

There are some other items that have to be considered for backend, it still takes over Zypper and YaST way more than it should, which dnf fixed by starting out lock for duration of PackageKit function, instead of duration of life of PackageKit process (it slows down PackageKit by a bit, but makes other tools collaborate with PackageKit better).

Honestly, I'm surprised no one thought of this before it was done for the dnf backend. It's kind of obvious...

...

Also backend doesn't refresh AppStream, which makes Gnome Software empty, that should be fixed using more of a repo approach than ZYpp backend (because ZYpp doesn't expose AppStream urls, so using librepo with as-glib would probably be a better idea).

It's a good plan, since that lets you freely fetch additional metadata from rpm-md however you like.

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