[Doc] Development Status

[shundhammer]

YQPkg Myrlyn Development Status

Scroll down all the way to see the latest status.

See also the list here.

• It's now a standalone binary executable

• It doesn't need any YaST shared lib or infrastructure anymore, just libzypp

• It can load the packages from the installed system

• New: Non-privileged user mode (read only):
  You can

  • Look what packages are installed and available
  • Search for packages by name, "requires" or "provides" dependencies
  • Experiment with "what if" scenarios, including resolving dependency problems

  You cannot install, uninstall, upgrade any packages. The "Accept" button is disabled.

• You can see in the window title if you are running it as a user ("YQPkg (read-only)") or with root privileges ("YQPkg [root]")

[shundhammer]

It's a Standalone Binary

Current screenshot as of 2024-11-21 10:30:

Removed - obsolete now

Notice the window title "YQPkg (read-only)" and the disabled "Accept" button: This was started as a non-privileged user.

[shundhammer]

We have Repo Content

Resolvables (packages, patterns, products, patches) from all active repos are now loaded, so it's already a lot more useful than previously when it just showed the already installed packages.

Notice that you can now also see the patterns that I don't have installed which are of course a lot more than those that I do have installed.

---

Getting this far was surprisingly complicated; I had to read a lot of code of the yast2-pkg-bindings and of zypper.

And right now there is no progress reporting at all yet (so it takes a while from the program start until you can see anything while all the data are loaded), it doesn't handle refreshing the repos or rebuilding the repo caches, and some scenarios (like software services) are not yet covered at all.

Most of this will probably come over time, but right now the emphasis is making it do something useful for the average user; like searching for packages (which it now actually does) and trying to install / updae / remove individual packages or patterns or a whole list of them, and see if the dependency resolver complains about it.

The commit phase where this is actually executed (where packages are actually installed / removed / updated) is still completely missing; it doesn't yet go beyond searching and experimenting what would happen.

Or just looking through lists and picking some of the packages that sound interesting to you. This is the whole reason of existence for this project, because this is something that command line does not do well.

If you know a package name or part of its summary or description, you can use zypper search and get it installed very quickly. But if you want some software to do a certain job, and you don't have a clue what packages with what names Linux has to offer, then what? You can trust your luck in Google and user forums, but you just can't browse through a pattern and look for packages that may fit your description, and then pick one or several of them and just try them out.

With yast2 sw_single (which may not be around for very much longer) - and now with yqpkg - you can.

Already yqpkg becomes immediately useful: You can use it to find the one or two packages that you want, and then, when you know their names, simply use zypper in <pkg-name>.

[shundhammer]

There is now instant feedback during the initialization phase: A splashscreen while the repos are loaded, and another while the package selector is created and populated with content.

Notice that while the active repos are now loaded, there is no repo refresh, and no prompting to import new GPG keys. It is recommended to do a manual sudo zypper ref before starting the program - or simply living with slightly outdated repos.

The commit phase (installing, removing, upgrading packages) is still completely missing.

But you can look, search, experiment with "what...if" scenarios (if you remove this or that package, or if you install one; and see what the dependency resolver has to say about it).

[shundhammer]

New 2024-12-02

We now have workflow functionality with a separate main window page for each workflow step:

• Initializing repos: For now just a placeholder page with a static text
• Package selection: Pretty much complete
• Package commit (installing / updating / removing packages): No actual package actions yet, just a visual mockup. Work in progress.
• Summary: For now just a placeholder page with a "Back" and a "Next" button

Screenshots

Page Navigation

Navigating between the pages already works, forward ("Next") and backward and to specific pages. Of course pages with no user interaction like the init phase do that automatically.

For example, when you click "Back" in the last page "summary" you will get back to the previous interactive step, the package selection. There is an actual page history, and some pages (repo init, package commit) are not stored in that history because it never makes sense to get back there while going backwards.

The Package Commit Page

The package commit page has mostly a big progress bar, but in addition to that it has a "[x] Show Summary Page" checkbox that you can check and uncheck while packages are being installed, so you can make the decision whether or not you want to see the summary page from where you can go back to do more package selection on a case by case basis while you have to wait anyway. If you uncheck that checkbox, the workflow will simply end after all selected packages are installed / updated / removed.

This will of course be stored in the config file so you'll see that checkbox how you left it when you get here the next time; it's no longer a setting that is pretty much hidden away (and thus hard to change - out of sight and out of mind) like it was in YaST.

And there is that "Show Details" mystery button. Yes, you will get details back while installing packages if you want to see them; so you won't feel that powerless and uninformed again like in the current YaST where you have no clue what is going on: What is currently being downloaded / installed, what is pending, what is already done. One click on the "Details" button opens that information. Stay tuned.

[shundhammer]

New 2024-12-03

First Summary Page

There is no real text content yet, but the rest of the functionality is there and working:

• The "Back" button takes you back to the package selection, so you can select more packages to install / update / remove.

• The "Finish" button (as you would have guessed) finishes the program workflow and quits the program.

• There is a countdown (30 seconds by default) that will also close this page and thus quit the program.

• You can stop the countdown with the "Stop" button, so you can take your time to read the text, or to decide if you want to go back to the package selection ("Back").

  When you hit the "Stop" button, the count

• The "..." button to the right of the "Stop" button lets you configure (and restart) the countdown:

  • Close after 10 seconds
  • Close after 30 seconds
  • Close after 60 seconds
  • Close after 300 seconds (5 minutes)
  • Don't automatically close (simply wait until you click the "Finish" button)

This is saved in the config file (~/.config/openSUSE/yqpkg.conf) and reused when starting the program again.

Remember that you can select in the previous screen (the commit phase) if you want to see this page at all - while you wait for the packages being installed.

[shundhammer]

New 2024-12-10

First Real Package Commit

You can now select packages for installation / update / removal to your heart's content in the PackageSelector, and for the first time, "Accept" actually does the package transaction: The packages will be installed / updated / removed.

First Real Commit Feedback

The progress bar on the "commit" page is now actually moving with real data from real libzypp callbacks.

Right now, it restarts for every package, and for packages that need to be downloaded it goes from 0% to 100% for the download, and then from 0% to 100% for the actual installation. But it's moving!

[shundhammer]

New 2024-12-11

First Real Summary

The summary on the summary page is now real, not just static data.

First Real Progress Reporting

The progress bar on the commit page is now real and moves correctly even with several package tasks.

The different phases of installing or removing a package are taken into account with their individual percentages and associated weights factors:

• Package download: 55% of the overall duration
• Unpacking the RPM: 30% of the overall duration
• Just handling the package: 15% of the overall duration

Of course, those values are just initial guesstimates and subject to change. But you get the idea.

New Screenshots

Commit Page with Details

Screenshot removed - obsolete now

When you click the "Show Details" button on the top right, you get those lists of packages:

• To do: Packages that are waiting to be processed.

  Packages waiting to be installed or updated are shown just with their names, packages that are waiting to be removed are shown with a leading - , very much like you would specify on a zypper install command line: sudo zypper in neweditor neweditor-lang -oldeditor -oldeditor-lang.

  For those who weren't aware of that: This kind of command line can both install and remove packages with one transaction, so dependencies won't get broken between different commands.

• Doing: Packages that are being processed right now.

  There might be more than one if libzypp decides to download and install in parallel, or to download a bunch of packages first and then install them.

• Done: Packages that are completed installing, updating or removing.

Summary Page with Content

Screenshot removed - obsolete now

Package tasks are grouped by category: Installed, updated, removed, failed, still to do (for example, if the user choose to cancel the transaction).

Right now, it shows only a limited number of each list ("(8 more)") to avoid overwhelming and scaring the user.

Yes, there is a lot of empty space on this page, but not all empty space needs to be filled.

This might still change heavily. Collapsed lists might become expandable. It might become user-configurable. But that's in the "nice to have" category and has low priority right now.

[shundhammer]

New 2024-12-17

Much Improved Commit Page Details

After a lot of real-life experiments (doing the manual GUI counterpart of a zypper up in batches), I found that two and a quarter lists didn't cut it. It was confusing to see tasks disappear from the left list ("To Do") until that one was completely empty, and they had all moved to the center list ("Doing") that intentionally was much shorter; it was intended for packages being processed in parallel.

But on distros like Tumblewed or Slowroll, libzypp is configured to download all packages in advance and only then start installing them one by one; that was the effect I observed. Since I am developing the program, of course I was following the log file (tail -F /etc/yqpkg-sh/yqpkg.log), and I could see what was going on; but that is an advantage the average user doesn't have, and shouldn't need. That's what the GUI and the "Details" view on the Commit Page are there for.

So I tried several different approaches. Adding icons to the packages that needed downloading was a big improvement (more below), but letting the task items move from the "To Do" list to the "Doing" list already was still confusing; even more so since the lists were automatically sorting alphabetically, so there was no way of knowing where a new task item just appeared.

So I went along and added a fourth list "Downloading", and I changed the lists (all but the left "To Do" list) to always append new items at the end, and to scroll to that position; just like a program's stdout output in a shell window (it helps to use behavioral patterns that the user already knows).

And this was what finally worked for me: I can now observe task items moving from the left "To Do" list moving to the center top "Downloads" list. As long as downloads are still going on, it's usually the bottom-most task that does not yet have the "download finished" icon with the checkmark; and that last item is always visible (unless you scroll the list up, which you can, of course).

And once all tasks have disappeared from the "To Do" list on the left, and the downloads are all complete, libzypp starts actually installing / updating / removing packages one by one: This is now the only thing that the "Doing" list shows. It also shows that this part does not use parallel processing: There is only one single item in "Doing", at least right now.

And as packages are finished being installed / updated / removed, they move to the right list "Done"; again, always added to the bottom of the list, and always scrolled to that position; very much like what you would see if you did the same thing with the zypper command line.

Some seconds after clicking "Accept" to start the commit phase: The first packages are downloaded.

Some small ones like "NetworkManager-applet", "avahi", "desktop-file-utils" were already finished downloading as you can see from the icon: Download + checkmark. "gdb" is currently being downloaded in this screenshot: Just the download icon without a checkmark.

Calculating the Total Progress

The progress bar is still showing 0% because there is still a lot of work ahead; those little packages are just a small fraction of the total size of the expected downloads.

The parts of work to be done is weighted for the total progress:

• 60% for the completed download so far
• 30% for actually unpacking the package or removing all its files, based on the installed size which is very different from the download size. For example, "qdirstat" has an installed size of 2.1 MiB, but a download size of just 718 kiB.
• 10% constant cost for handling a package task.

Pre- and post-install/uninstall scripts are still very much disregarded; it's hard to compare anyway. Most packages don't do anything in those scripts, while others (kernel, grub2) do a full-fledged "dracut" run which can take minutes. Others still like the NVidia drivers need to build (compile and link) a kernel module in their post-install script which can take several minutes.

Don't get hung up on the details of the global progress; it's only a very rough estimate.

Here you can see how the "Downloads" list scrolls down as new tasks are added, so you can always see what package is currently being downloaded. In this case, it's "xfce4-weather-plugin".

Still, no package has actually been installed / updated / removed yet; in this setup, libzypp waits until all the needed downloads are finished.

Closing the details view with the "Hide Details" button to show the default view.

Some users might prefer that. But hey, we are nerds; we want more details. Why else would we use this program in the first place? 😃

Of course, you won't get details until you click the "Show Details" button, but when you do, this will be the default view for the next program start.

All downloads are done, so packages are actually being installed / updated / removed: The left "To Do" list is empty, the "Downloads" list is filled, and even the last package in "Downloads" shows the "Download finished" icon.

"kernel-default" is currently being installed, and some first packages are already in the "Done" list; in the order in which they were done.

Screenshot removed - obsolete now

The summary page for this. Usable, but still work in progress.

[shundhammer]

New 2024-12-19

Improved Summary

This implements #16 :

Packages are now shown by task category (remove / install / update) and split up between "by user" or "by dependency", where you get to see more "by user" list items if the whole list is short anyway.

Also, the "(xy more)" list cut-off is now a bit more flexible: It now avoids "(1 more)", "(2 more)", "(3 more)" if it's just up to 3 items more than would normally be displayed.

[shundhammer]

About the Removed Screenshots

You may have read that I removed earlier screenshots. Why? Because some bloggers (not all) just grab the first one that they see and post it in their blog, completely ignoring that it's an outdated one, and the current thing looks much different. They simply never read any text, they just grab the first one that looks colorful enough.

So I removed those that would be grossly misleading and misrepresent the current state of the project. This destroys the history of this development status protocol, but if that's the price for not seeing misleading images of my work floating around the Internet, so be it.

[shundhammer]

New 2024-12-23

Proudly Presenting a Graphical 'zypper dup' and 'zypper up'

We now have a new filter view "Updates":

This is an addition, not a replacement for the "Patches" view (hit F2 to get the "Patches" view).

You see only the "blue" packages here, i.e. those that can be updated. And there are the buttons for "Package Update" and "Dist-Update", i.e. the exact same thing that zypper up or zypper dup does.

This is the first important new feature that YQPkg has and YaST does not.

More details at issue #7.

[shundhammer]

New 2024-12-25

Intelligent 'Auto' Search Mode

The "Search" filter view (which is arguably the single most important view) received a massive overhaul. Not only did I change all that really ugly boilerplate code to create and lay out widgets to using a Qt Designer form (which massively reduced the code of that YQPkgSearchFilterView class), I also imported some code from my QDirStat for guessing the search mode:

We always had search modes

• Contains
• Begins with
• Exact match
• Wildcards
• Regular expression

And now we have one more: Auto. That one guesses from what you type what search mode you probably want: If you are using special characters commonly used in regular expressions like ., [, ^, $, that means you most likely want a regexp. If you use lone * or ?, you most likely want wildcards.

There is also a special character = at the start of the search pattern where you can select "exact match" without leaving "Auto" mode.

And if none of those is present, it uses "starts with" as a default.

Of course this is not 100% exact, so you can still explicitly switch to any of the other search modes.

Example:

You can see what the Auto mode guesses as you type, so you can change the search mode if it guesses wrong.

[shundhammer]

New 2024-12-29

File Conflicts Check during Commit

We now have progress reporting for the file conflicts check during commit: That was the delay between finishing downloading the last package to download and beginning to install the downloaded packages. Libzypp checks the actual downloaded packages for their file lists (because only then the file lists are definitely known) and if there are any duplicate file list entries between them, i.e. if there are any file list conflicts.

Normall, that's very quick (under one second), but depending on the amount of packages to install or to upgrade, it can take considerably longer. If it takes longer than 1.5 seconds, you now get a pop-up dialog with a progress bar:

The dialog is non-modal, i.e. you can still click widgets in the main window. The dialog's "Close" button only closes the progress pop-up, it doesn't cancel the file conflict check or the commit. But since the dialog is not modal, you can still click the "Cancel" button in the main window (and answer the confirmation if you really want to cancel the transaction).

If there are any file conflicts, the first 6 of them will be reported in a separate warning pop-up each:

More details (why 6 etc.) at issue #13.

[shundhammer]

New 2024-12-31

Repo Refresh is Implemented

When run as root (real root, not --fake-root), the enabled repos are now automatically refreshed. User feedback is still work in progress after two failed attempts - see #5 for (lots of) details.

This was the last major missing feature to make the program usable without resorting to command line tools; you don't need to invoke sudo zypper ref anymore for smooth operation.

Unless you just cleaned the repos (sudo zypper clean -a) and start it as a non-root user, in which case it even tells you that you need to run sudo zypper ref.

There is still no GPG key handling yet, but that's a rare exceptional thing that is only needed just after a new repo has been added that is not in the GPG keyring yet.

[shundhammer]

New 2025-01-01

Repo Refresh Progress

(see also #5)

This shows how enabled repos are found on the system (i.e. they show up in this list), how they are refreshed (the download from the remote repo starts) and how the refresh is finished (the "download finished" icon with the checkmark).

The progress bar at the bottom is just a very rough indicator with one step for each repo as it is processed.

This is the best we can get with the current technology.

In real life, most of the times it just flashes by in very few seconds. Only when a large remote repo really needs being refreshed it takes longer, but at least it's now broken down by repos so you don't feel so completely lost while staring at a simple static text message like it used to be.

[shundhammer]

New 2025-01-05

• Fixed the initial package list and details view content (or lack of it); see Initial Selection in Package List and in Details View #10

• Improved the visual appearance; margins, spacings, less cramped, less baroque pseudo-3D-effects; see Improve the Visual Appearance #35 (including screenshots before and after)

[shundhammer]

Project renamed from YQPkg to Myrlyn

See also #19

[sjvudp]

Adding icons to the packages that needed downloading was a big improvement (more below), but letting the task items move from the "To Do" list to the "Doing" list already was still confusing; even more so since the lists were automatically sorting alphabetically, so there was no way of knowing where a new task item just appeared.

Well, I just found this, and I feel like commenting, even if it's much too late:
I wonder: What about using a completely different approach, using an icon (or a character in TUI) to indicate the status of an item (like "to do", "done", "failed", or even more detailed like "downloading", "processing", "installing", etc.,)? You could still have three columns: #1: incomplete (in progress), #2:, successful, #3: failed

In case you are watching biathlon occasionally, the shooting display is quite similar: Each athlete in the list has to do 5 shots, and their task is complete once the 5 shots were made (then they disappear from the list). However there are two different outcomes: If all shots were on the target, the athlete continues normally, but if at least oje shot failed, they have to make extra "penalty" rounds.

So the order of column #1 won't change, but items may be removed from in between (and maybe (in the biathlon case) new items added at the end). Likewise for columns #2 und #3 items would be appended at the end.

[shundhammer]

Package Commit Progress Discussion

I considered this and decided against it: In most use cases where this is even relevant, there are way more packages than fit on the screen at the same time, so you get a scrolled list. And you can bet that most of the action is scrolled away; you only see a little "peephole" of the overall scene. There is no way to keep track of changes, so you'll mostly stare at a static display again, because the action is out of your sight.

With several lists, you get more information:

• The first list "to do" gives you rough indication of the amount of tasks that are still waiting. The scrollbar is a hint how much of the total you see, and as the list shrinks and finally becomes empty you can clearly see that things are moving along.

• The center "downloads" list shows you the amount of packages that are already downloaded, and new downloads are always added to the end, so you can observe the amount of packages that are finished downloading, and which one is the current download. It even leaves the potential for libzypp to actually download in parallel; then the currently active downloads would also be at or near the end of the list.

• The center bottom "doing" list shows what package is currently being installed, updated or removed. Again, this has the potential of parallel processing if libzypp maybe can do that in the future. Right now it's only one single entry, though.

• The right "done" list shows what packages are finished.

The movement of packages (or, more precisely, package tasks) through the list gives a much more dynamic impression that the static screenshots lead you to believe: As libzypp picks one of them from "to do" and downloads it (unless it's a "remove" task which is shown as - packagename), processes it, and is finished.

This window makes use of the known libzypp behavior that it does all downloads in advance (in this configuration), so while there are still pending downloads, the center "downloads" list is automatically scrolled to the bottom whenever a new download is added; exactly like a scrolling terminal window.

But when libzypp starts actually processing packages (install, update, remove), that list is scrolled to the top from where the next one will be picked, so you can observe how the next package is taken out of the "downloads" list and moves to the "doing" list and then to the "done" list.

Try it to get an impression. It's now safe to use Myrlyn for day-to-day operation; you can do a graphical dist update (the zypper dup counterpart) to experience what it feels like.

Of course, the usual caveats apply; it's still software in development, so bugs can happen. But at the package commit stage, that would be very uncommon; about as uncommon as doing the same with a zypper dup or in YaST.

[shundhammer]

New 2025-01-14

Patches View

If the system provides any patches (Leap, SLE), the "Patches" view is now automatically available:

If the system does not have any patches (Tumbleweed, Slowroll), that view does not make any sense. so you won't get it by default. There is still the old [F2] key to activate it.

Fun fact: This has been in YaST Qt for the past 20+ years, for debugging as well as for real use as an alternative to the YQSimplePatchSelector which you got when you started yast2 online_update.

Number of Patches / Updates in the Tab Labels

You can still use the "Updates" view if you prefer that one. Both "Patches" and "Updates" now show the number of available patches (or package updates, respectively) in their tab labels so you can instantly see if it's even worthwhile to click into them:

Notice that not all repos offer patches, even for distros that have them, like Leap; especially third-party repos like Packman or NVidia simply provide updated packages.

But even for repos that do offer patches, you can also simply update all the packages that belong to them in the "Updates" view: A patch is satisfied if all the package versions that it provides are installed.

[shundhammer]

New 2025-01-16

Importing Repo GPG Keys is Implemented

(see also #6)

If you click on "Trust", of course the GPG key is imported into the libzypp key ring.

If you click on "Cancel", this repo is disabled for the duration of this program run:

[shundhammer]

New 2025-01-18

• Fixed Myrlyn Minor: No Magic #61

[shundhammer]

New 2025-02-06

Implemented Repository Configuration

See #69 for more details.

[shundhammer]

New 2025-02-19

New Logger in Preparation for the Migration to Qt 6

#70 was the last remaining big obstacle to migrate to Qt 6. This is now resolved.

Qt 6 Migration Imminent

Qt 5 will go out of support around May 2025, so it's about time to migrate to Qt 6. A lot of small things are already done thanks to @gruenich; now it's time to do the last steps:

• Change the CMake environment from Qt 5 to Qt 6
• Actually use Qt 6 headers and libraries
• Test! Test! Test!
• Find and fix the remaining small and (hopefully few or none) large issues
• Migrate the documentation (build requirements etc.), too
• Migrate the .spec file for OBS

[shundhammer]

New 2025-02-25

New Release Myrlyn-0.9.2 Based on Qt-6

The Qt 6 port is now ready thanks to a joint effort of @gruenich and myself; we fixed the remaining "deprecated" warnings and some things that have changed between Qt 5.x and Qt 6.x, and it's working now. The qt6-branch is now merged to master, and the resulting version is now tagged as 0.9.2.

Packages with that latest version are now available in myrlyn-stable and myrlyn-git in my OBS home project. Notice that they now require Qt 6 packages.

See also here.

Package Commit Page now Defaults to Showing Details

After I had to do that manually so many times after removing my ~/.config/openSUSE/Myrlyn.conf file, I now changed the default on the package commit page to showing details, no longer just the plain progress bar.

If you interested users out there are anything like me, you want the details by default. Why? Because we are nerds. Why else would we use this program in the first place? 😄

For those few users who don't want this, the plain progress bar with nothing else to disturb the boredom is just one mouse click away.

Wrong Git Tag 9.0.1 (Fixed)

While I was working on that 0.9.2 release I realized with horror that I had a typo in the previous tag: It was meant to be 0.9.1, but it was actually 9.0.1. The version number in the VERSION.cmake and packages/myrlyn.spec files were correct, but the tag was wrong.

Unfortunately this also lead to some packages in OBS wrongly versioned as myrlyn-9.0.1 which now causes some trouble. Sorry for that.

If you installed one of those 9.0.1 packages, the easiest way to move on to the correctly versioned new myrlyn-0.9.2 is to remove the old one manually (sudo rpm -e myrlyn-9.0.1) and then install the new one instead.

Make sure to use zypper in myrlyn-0.9.2 (not just rpm -Uhv myrlyn-0.9.2*.rpm) to get the Qt 6 packages that it now requires.

Sorry for he inconvenience. 😢

I also tagged that wrongly tagged version with the correct 0.9.1 tag and removed the bad 9.0.1 tag. The myrlyn-0.9.2 packages now also contain an Obsoletes: myrlyn = 9.0.1.

Potential Graphics Problem for some Semi-HiDPI Setups

Qt 6 has a new way of handling HiDPI graphics setups (don't they always...) that has pros and cons.

See #79 and the workaround described there. I had that problem on my laptop that isn't really HiDPI with its 160 physical dpi, but close enough to cause trouble if you changed it to keep fonts readable and icons large enough to recognize. More at #79.

[shundhammer]

New 2025-02-28

More Feedback after "Package Update" or "Dist Upgrade"

Depending on what distribution you are using, not all "Package Update" or "Dist Upgrade" actions are always 100% successful: Some packages might be left over; they couldn't be updated without any dependency problem.

That's okay in most situations; some updates might be a bit delayed, but they will normally be released in a couple of days. Other packages might depend on those pending updates, and only then those packages can also be updated. This might lead to a bit of irritation to the uninitiated, but it's actually quite a normal situation.

Now there is some status feedback for this on Myrlyn's "Update" page.

Before the Update / Upgrade

Remember that on this page, the package list only shows packages that could potentially be updated; i.e. there is a newer version available than the installed one. Still, an attempt to update them could lead to a dependency problem for each one. We don't know that yet; only if we try.

You could click on each package's status icon individually to set the next logical status ("update" in this case), but this might be a lot of clicks, and the dependency resolver would run after each click which means some seconds of delay. And if it doesn't work flawlessly, you will get a dependency conflict window where you need to make a decision how to continue; "don't install version XY" is the best solution in this situation.

Or you could let the dependency resolver do that for the packages that can be updated without a problem: With the "Package Update" or the "Dist Upgrade" button. The difference between both is subtle; "Dist Upgrade" goes a bit further than "Package Update" in taking more things into account like package splits and renames, and also changes in the patterns; if your KDE Plasma received more packages that are now recommended, you will get those as well with "Dist Upgrade", to name just one example.

So, let's click on "Dist Upgrade" here.

After the Update / Upgrade

You can see more icons here: A checkmark for packages that could be set to "update" without any dependency problem, and a sad face emoji for those that could not. When you click on "Accept" to execute the update (and other pending changes) and then come back, you will be stuck with the sad-faced packages: Try again on another day. Or in a few hours.

The icons are just temporary; they will disappear when you change to another view, or even when you click the "Refresh List" button. But if you like sad faces around you, click "Dist Upgrade" again, or try "Package Update" instead (hint: that probably won't help).

Coming back and letting those ungrateful suckers suffer

This situation is more common on Slowroll because it doesn't receive package updates so often; that's a feature, not a bug. On the downside, it might take a few days until those leftover packages can be updated as well.

[shundhammer]

New 2025-03-14

Package Metadata Translations

We have package metadata translations. Or rather, there is proof that we could have them from the side of Myrlyn if they weren't so appallingly incomplete. See #3.

[shundhammer]

New 2025-03-15

No Redundant "Automatic Changes" Pop-Up Anymore

Whenever the dependency resolver needed to install, update or remove any packages automatically, you will be notified about that in a pop-up dialog when you click on the "Accept" button; just to ensure that you know about such changes that you didn't explicitly request.

But that's redundant and actually quite annoying if you switched to the "Installation Summary" page anyway to see what you will get; the default view includes those automatic changes. In that case, you will now no longer have to click away that additional pop-up dialog; its content is already visible in the main window's package list.

No more additional "Automatic Changes" pop-up dialog if this is your current page.

If you uncheck showing the automatic changes in that view ("Auto-Install", "Auto-Update", "Auto-Delete"), however, the pop-up will still appear. Also if you check the "Keep" check box because then the automatic changes will definitely be drowned out by all the packages that you already have installed.

[shundhammer]

New 2025-03-24

Stress Test: Myrlyn dup with 3800 Packages to Update

Oopsie: 3800 Updates!

This was a bit unvoluntary, but it was a very useful test nonetheless: I hadn't updated my Tumbleweed VirtualBox VM for 4 weeks. A lot of updates had accumulated during that time: 3800 of 3822 installed packages needed to be updated.

Of course I used Myrlyn to do that; it was what told me on the "Updates" tab that there were 3800 (yikes!) pending updates. So I clicked "Dist Upgrade" and switched to the "Installation Summary" tab to see what it planned to do; there were quite a number (29) of packages to remove, and an even larger number (259) of new packages to install, both because of dependencies.

Hint: In this situation, when there are so many updates, it's useful to uncheck "Automatic Updates" in the "Installation Summary" tab to concentrate on the packages that will be added (the packages to remove are the first ones anyway). And when almost all packages need an update like in this particular case, it would also be useful to check "Keep" because it's so few of them that will not be changed.

Starting it

A click on "Accept" immediately starts the transaction: All those packages need to be downloaded which takes quite a while with a number that large.

Download Errors!

At some point, I got several errors that some packages could not be downloaded. This sounds suprising, but if the download takes half an hour or more, chances are that some of those packages are already being updated again on the download server. For a rolling release like Tumbleweed, only the latest version of each package is kept on the download server; any older versions are already removed.

And Myrlyn / libzypp are still using the repo metadata from the time when the program was started (same with zypper or YaST), so the versions that they expect may already be a bit out of date at that point: If libfoo-47.11 was the latest one half an hour ago (when the program was started and the repo was refreshed), but now the download server already has libfoo-47.12 (and libfoo-47.11 is no longer available), there will be a download error.

Don't Fear the Reaper Download Errors

In this case, it's best to answer the download error pop-up ("Abort", "Retry", "Ignore") with "Ignore" and just carry on downloading as much as possible; and when libzypp later runs into an unrecoverable error because not all the packages could be downloaded, simply exit the program and restart it so it refreshes the metadata, then click "Dist-Upgrade" again.

Keep a Stiff Upper Lip and Carry On Regardless

No harm will be done: Remember, we are always downloading all packages in advance before any package is updated / installed / removed; simply restart because this time the package caches are filled, so the download phase will be really fast.

Rinse and Repeat

Just keep repeating the process until everything is successfully downloaded, and it starts actually installing / updating / removing packages.

You can tell from the "Done" list on the right side being filled, and no more packages waiting in the left side "To Do" list (the ones starting with a minus ("- foobar") are the ones that need to be removed; they don't need to be downloaded, of course):

And when all downloads come from the cache, there is no need to download any more packages, so the whole huge transaction (3800 packages in this case) can be done without any further download errors, even if the download server is being updated again in the meantime.

Success!

In my case with 3800 pending updates, this whole process took a while; over 3 hours. The limiting factor is mostly the download speed of the server. And running it inside a VM doesn't make the network speed any faster.

Log file highlights from the first program start:

2025-03-24 10:40:34.329 [2548] <Info>    Logger.cc:124 openLogFile():  -- Log Start --
2025-03-24 10:40:34.329 [2548] <Info>    main.cc:119 logVersion():  myrlyn-0.9.2 built with Qt 6.8.2
...
...
2025-03-24 10:41:17.251 [2548] <Info>    YQPkgConflictDialog.cc:240 doDistUpgrade():  Starting a dist upgrade ('zypper dup' counterpart)
...
2025-03-24 10:42:16.187 [2548] <Debug>   YQPkgSelector.cc:1459 showAutoChangesDialog():  Already showing automatic changes in the main windwow, skipping pop-up dialog
...
...
2025-03-24 10:42:16.532 [2548] <Debug>   MainWindow.cc:100 showPage():  Showing page PkgCommitPage class PkgCommitPage
2025-03-24 10:42:23.307 [2548] <Debug>   PkgCommitPage.cc:406 initProgressData():  total download size:  2.85 GiB
2025-03-24 10:42:23.308 [2548] <Debug>   PkgCommitPage.cc:407 initProgressData():  total installed size: 10.94 GiB
2025-03-24 10:42:23.308 [2548] <Debug>   PkgCommitPage.cc:408 initProgressData():  total tasks: 3812
...
2025-03-24 10:42:23.309 [2548] <Info>    PkgCommitPage.cc:211 realCommit():  Starting package transactions
2025-03-24 10:42:27.622 [2548] <Verbose> PkgCommitPage.cc:568 pkgDownloadStart():  <PkgUpdate Mesa-KHR-devel>
2025-03-24 10:42:27.812 [2548] <Verbose> PkgCommitPage.cc:634 pkgDownloadEnd():  <PkgUpdate Mesa-KHR-devel>
2025-03-24 10:42:27.827 [2548] <Verbose> PkgCommitPage.cc:568 pkgDownloadStart():  <PkgUpdate Mesa-libva>
2025-03-24 10:42:27.996 [2548] <Verbose> PkgCommitPage.cc:634 pkgDownloadEnd():  <PkgUpdate Mesa-libva>
...
...
2025-03-24 10:59:34.127 [2548] <ERROR>   PkgCommitPage.cc:964 pkgActionError():
    pkgDownloadError(): libdbusmenu-gtk3-4:
    Failed to provide Package libdbusmenu-gtk3-4-16.04.0-10.8.x86_64 (Tumbleweed OSS). Do you want to retry retrieval?

[repo-tw-oss|http://download.opensuse.org/tumbleweed/repo/oss/] Can't provide file './x86_64/libdbusmenu-gtk3-4-16.04.0-10.8.x86_64.rpm' from repository 'repo-tw-oss'
History:
 - Location 'http://download.opensuse.org/tumbleweed/repo/oss/x86_64/libdbusmenu-gtk3-4-16.04.0-10.8.x86_64.rpm' is temporarily unaccessible.
 - Can't provide ./x86_64/libdbusmenu-gtk3-4-16.04.0-10.8.x86_64.rpm
...
...
2025-03-24 11:00:53.209 [2548] <ERROR>   PkgCommitPage.cc:964 pkgActionError():
   pkgDownloadError(): libQt6Quick3DRuntimeRender6:
   Failed to provide Package libQt6Quick3DRuntimeRender6-6.8.2-2.1.x86_64 (Tumbleweed OSS). Do you want to retry retrieval?
2025-03-24 10:59:42.710 [2548] <Verbose> PkgCommitPage.cc:568 pkgDownloadStart():  <PkgUpdate libclutter-1_0-0>
2025-03-24 10:59:43.119 [2548] <Verbose> PkgCommitPage.cc:634 pkgDownloadEnd():  <PkgUpdate libclutter-1_0-0>
2025-03-24 10:59:43.170 [2548] <Verbose> PkgCommitPage.cc:568 pkgDownloadStart():  <PkgUpdate libcanberra-gtk3-0>
2025-03-24 10:59:43.386 [2548] <Verbose> PkgCommitPage.cc:634 pkgDownloadEnd():  <PkgUpdate libcanberra-gtk3-0>
...
...
[repo-tw-oss|http://download.opensuse.org/tumbleweed/repo/oss/]
  Can't provide file './x86_64/libQt6Quick3DRuntimeRender6-6.8.2-2.1.x86_64.rpm' from repository 'repo-tw-oss'
History:
 - Location 'http://download.opensuse.org/tumbleweed/repo/oss/x86_64/libQt6Quick3DRuntimeRender6-6.8.2-2.1.x86_64.rpm' is temporarily unaccessible.
 - Can't provide ./x86_64/libQt6Quick3DRuntimeRender6-6.8.2-2.1.x86_64.rpm
2025-03-24 11:01:11.228 [2548] <Info>    PkgCommitPage.cc:219 realCommit():  libzypp aborted as requested
...
2025-03-24 11:01:17.046 [2548] <Debug>   main.cc:151 main():  MyrlynApp finished.

Log from the last Myrlyn start where most packages were already cached:

2025-03-24 11:17:31.259 [6991] <Info>    Logger.cc:124 openLogFile():  -- Log Start --
2025-03-24 11:17:31.260 [6991] <Info>    main.cc:119 logVersion():  myrlyn-0.9.2 built with Qt 6.8.2
...
...
2025-03-24 11:17:40.469 [6991] <Info>    YQPkgConflictDialog.cc:240 doDistUpgrade():  Starting a dist upgrade ('zypper dup' counterpart)
2025-03-24 11:17:40.776 [6991] <Info>    YQPkgConflictDialog.cc:245 doDistUpgrade():  Dist upgrade done after 0.307 sec
2025-03-24 11:17:46.813 [6991] <Info>    YQPkgSelectorBase.cc:302 showPendingLicenseAgreements():  Showing all pending license agreements
2025-03-24 11:17:46.841 [6991] <Debug>   YQPkgSelector.cc:1459 showAutoChangesDialog():  Already showing automatic changes in the main windwow, skipping pop-up dialog
...
...
2025-03-24 11:17:53.815 [6991] <Info>    PkgCommitPage.cc:211 realCommit():  Starting package transactions
2025-03-24 11:17:58.056 [6991] <Verbose> PkgCommitPage.cc:664 pkgCachedNotify():  <PkgUpdate Mesa-KHR-devel>
2025-03-24 11:17:58.139 [6991] <Verbose> PkgCommitPage.cc:664 pkgCachedNotify():  <PkgUpdate Mesa-libva>
2025-03-24 11:17:58.229 [6991] <Verbose> PkgCommitPage.cc:664 pkgCachedNotify():  <PkgUpdate ModemManager-bash-completion>
...
...
2025-03-24 11:27:15.187 [6991] <Verbose> PkgCommitPage.cc:664 pkgCachedNotify():  <PkgUpdate patterns-xfce-xfce_basis>
2025-03-24 11:27:15.354 [6991] <Verbose> PkgCommitPage.cc:664 pkgCachedNotify():  <PkgUpdate patterns-xfce-xfce>
2025-03-24 11:27:15.515 [6991] <Debug>   PkgCommitPage.cc:1034 fileConflictsCheckStart():  
2025-03-24 11:27:17.245 [6991] <Debug>   ProgressDialog.cc:61 showDelayed():  Showing progress dialog "Checking File Conflicts..."
2025-03-24 11:27:54.254 [6991] <Debug>   PkgCommitPage.cc:1074 fileConflictsCheckResult():  
2025-03-24 11:27:54.254 [6991] <Info>    PkgCommitPage.cc:1079 fileConflictsCheckResult():  File conflicts check finished after 38.739 sec
2025-03-24 11:27:54.283 [6991] <Verbose> PkgCommitPage.cc:835 pkgActionStart():  <PkgRemove libboost_program_options1_86_0-devel>
2025-03-24 11:27:55.583 [6991] <Verbose> PkgCommitPage.cc:921 pkgActionEnd():  <PkgRemove libboost_program_options1_86_0-devel>
2025-03-24 11:27:55.590 [6991] <Verbose> PkgCommitPage.cc:835 pkgActionStart():  <PkgRemove libboost_test1_86_0-devel>
2025-03-24 11:27:56.486 [6991] <Verbose> PkgCommitPage.cc:921 pkgActionEnd():  <PkgRemove libboost_test1_86_0-devel>
...
...
2025-03-24 13:39:37.347 [6991] <Verbose> PkgCommitPage.cc:835 pkgActionStart():  <PkgUpdate patterns-base-x11_enhanced>
2025-03-24 13:39:38.516 [6991] <Verbose> PkgCommitPage.cc:921 pkgActionEnd():  <PkgUpdate patterns-base-x11_enhanced>
2025-03-24 13:39:38.604 [6991] <Verbose> PkgCommitPage.cc:835 pkgActionStart():  <PkgUpdate patterns-xfce-xfce_basis>
2025-03-24 13:39:40.010 [6991] <Verbose> PkgCommitPage.cc:921 pkgActionEnd():  <PkgUpdate patterns-xfce-xfce_basis>
2025-03-24 13:39:40.093 [6991] <Verbose> PkgCommitPage.cc:835 pkgActionStart():  <PkgUpdate patterns-xfce-xfce>
2025-03-24 13:39:41.245 [6991] <Verbose> PkgCommitPage.cc:921 pkgActionEnd():  <PkgUpdate patterns-xfce-xfce>
2025-03-24 13:43:19.624 [6991] <Info>    PkgCommitPage.cc:215 realCommit():  Package transactions done
2025-03-24 13:43:19.624 [6991] <Debug>   MyrlynWorkflowSteps.cc:118 nextPage():  _app->next()
2025-03-24 13:43:19.624 [6991] <Debug>   MyrlynApp.cc:380 next():  Current page: pkgCommit
2025-03-24 13:43:19.624 [6991] <Debug>   MyrlynApp.cc:400 next():  Next step in the workflow.
2025-03-24 13:43:19.624 [6991] <Debug>   MyrlynWorkflowSteps.cc:102 activate():  Activating step summary
2025-03-24 13:43:19.658 [6991] <Debug>   MainWindow.cc:100 showPage():  Showing page SummaryPage class SummaryPage

Do it Again, Sam Myrlyn!

If it takes that long, consider restarting it once again: More new updates may have become available on the server in the meantime.

Bottom Line

Myrlyn is very stable now.

I am using it on all my systems to keep them up to date and of course also for all package installation / removal tasks. I've been doing that since last Christmas (2024).