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