Expectations of SlowRoll Users: Diverging from the Tumbleweed Experience

I had confirmation of that behaviour with Tumbleweed on one of the MLs a few weeks ago, so this would be true for Slowroll as well.

1 Like

Nope:

erlangen:~ # grep ^solver /etc/zypp/zypp.conf 
solver.onlyRequires = true
solver.allowVendorChange = true
solver.dupAllowVendorChange = true
erlangen:~ # 

Users may want to undo the restrictive default configuration and enable vendor change again. They call it “brute force”. However considerate usage of vendor change does away with most issues of distribution upgrade:

“Note that there can be some subtleties with updates, especially with multiple repositories. See for example recent discussion about using zypper dup versus zypper up and zypper dup priorities.”

https://en.opensuse.org/Portal:Tumbleweed

" zypper dup ensures that all installed packages come from one of the available repositories. It does not consider the version or architecture, but prevents changing the vendor of the installed packages by default, using the --no-allow-vendor-change option. If you have third-party repositories enabled, some repositories may break during the upgrade. In this case, use --allow-vendor-change instead."

The GUI updater relying on PackageKit and Yast2 use libzypp too. Some implementation details differ, e.g. The package glibc is essential to correct operation and cannot be removed using this tool - #41 by karlmistelberger. This warrants some extra fun Tumbleweed folks aren’t asking for.

2 Likes

I am impressed by the experts’ posts here. :face_with_monocle:

Maybe i am a good example for the lower end of Leap Users, which shall one day migrate to Slowroll: :smiling_face:
I am not into Terminal orgies :nauseated_face:, dislike anything that forces me to google for solutions, which include the risk of shredding my system :scream:. I like a well designed GUI :+1:, that allows the user to configure what’s of interest without breaking anything :nerd_face:. That’s why i went for Suse, because YaST is awesome! :heart_eyes:

So my expectations in Slowroll would be simple:
It should be the same as Leap/YaST, but with more & smarter updates.

1 Like

@BierPizzaChips If you want that stability, then look at MicroOS, on Tumbleweed likewise only stick to the standard repos (oss, non-oss and update) use flatpacks… and should have a very similar experience to Leap.

2 Likes

Other than a few hiccups early on (all resolved), Slowroll has been running quite nicely on two external USB SSD’s with both kernel-default and (the new) kernel-longterm installed. I’ve been booting into them using kernel-longterm.

I kept the fs as btrfs on these drives, as well as on my Tumbleweed desktop (BIOS) installs.

Install is smooth experience. Followed the instructions and got the following:

slowroll:~ # zypper repos -uEP
# | Alias        | Name         | Enabled | GPG Check | Refresh | Priority | URI
--+--------------+--------------+---------+-----------+---------+----------+-----------------------------------------------------------------------------
6 | packman      | packman      | Yes     | (r ) Yes  | Yes     |   70     | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Slowroll/Essentials/
7 | update       | update       | Yes     | (r ) Yes  | Yes     |   80     | http://cdn.opensuse.org/update/slowroll/repo/oss/
1 | base-non-oss | base-non-oss | Yes     | (r ) Yes  | Yes     |   99     | http://cdn.opensuse.org/slowroll/repo/non-oss/
2 | base-oss     | base-oss     | Yes     | (r ) Yes  | Yes     |   99     | http://cdn.opensuse.org/slowroll/repo/oss/
5 | h264         | h264         | Yes     | (r ) Yes  | Yes     |   99     | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/
slowroll:~ # 
slowroll:~ # snapper list
 # | Type   | Pre # | Date                     | User | Used Space | Cleanup | Description           | Userdata     
---+--------+-------+--------------------------+------+------------+---------+-----------------------+--------------
0  | single |       |                          | root |            |         | current               |              
1  | single |       | Tue Jan 16 08:36:38 2024 | root | 116.00 KiB | number  | first root filesystem |              
2  | single |       | Tue Jan 16 08:44:31 2024 | root |  22.49 MiB | number  | after installation    | important=yes
3  | pre    |       | Tue Jan 16 08:56:23 2024 | root |  23.43 MiB | number  | zypp(packagekitd)     | important=yes
4  | post   |     3 | Tue Jan 16 09:03:06 2024 | root |  64.87 MiB | number  |                       | important=yes
5  | single |       | Tue Jan 16 12:24:18 2024 | root | 116.00 KiB | number  | rollback backup of #1 | important=yes
6* | single |       | Tue Jan 16 12:24:19 2024 | root | 105.77 MiB |         | writable copy of #2   |              
7  | pre    |       | Tue Jan 16 12:33:24 2024 | root |  16.08 MiB | number  | zypp(zypper)          | important=yes
8  | post   |     7 | Tue Jan 16 12:37:29 2024 | root |  42.30 MiB | number  |                       | important=yes
slowroll:~ # 

At least on Tumbleweed, Discover does that already (Discover → packagekit → zypper dup). I assume it will be the same on Slowroll.

2 Likes

Why is recommended to set pacman priority at 70 and update at 80 (or lower than base repos)?
Whouldn’t it be ok to have all at the same priority (99)?

I posted frequently on priorities and got many embarrassing comments: Search results for 'zypper priorities @karlmistelberger' - openSUSE Forums

You may watch openSUSE Conference 2018 - Repository priorities for the real world user and try yourself.

3 Likes

Can’t thank you enough for recommending this video to me in the past. Best 10 minutes of content to prevent 99% of future repo issues. :100:

1 Like

And, if I have it correct, when KDE6 Plasma is released on S.R., that feature will disappear.

Right. But if you install “discover-notifier” then that will serve as a tray icon to indicate updates are available. And if you click it you will get “discover” which can update your system and should be using the equivalent of “zypper dup”.

1 Like

I disagree about almost nothing.
The only point I agree with is number 3.
Point 1 Pre-installed applications are not mandatory, during installation it is possible to deselect and block them, however the fact that they are there is positive, because it means that these applications are tested and working, tests are not done for non-default applications, furthermore they are all applications that a user normally uses and their weight is truly insignificant today.
Point 2 btrfs file system, it is exactly the opposite of what you say, the fact of having old hardware is irrelevant, but in this way the user has the possibility to restore his system in case an update is not successful or due to of an incorrect setting that the user has changed.
It’s really suitable for beginners and it amazes me that other distributions like Ubuntu (for humans) don’t have it yet (we’re in 2024).

I like btrfs as much as anyone else, but it’s not for the hands-off admin/user.
In addition to the unstable features like raid5/6 that btrfs ships albeit with a warning (IMHO a filesystem should never do that), there are several other issues with it in the latest kernel versions:

In your opinion, SUSE is a company that develops enterprise distributions and many other companies send their customers an unstable and even dangerous file system? It would not make sense.
The only limitation is RAID56, but I don’t think there are many users using it nowadays.
“This is not intended to replace official documentation” seems so from the moment you post it.
It is not even true that it is not suitable for the user who does not intervene, I have always used the default settings and have never had any problems.
The opposite is true, btrfs has saved me on several occasions thanks to automatic snapshots, a system that all modern systems have or should have today.

Perhaps it could be the major issue with btrfs quota/qgroup does not affect older kernels, but it is definitely not isolated to my use case or machine, not only have I reproduced it in a VM but I’ve helped others here with the same issue.

Can’t speak for Leap/SLE as I use Slowroll (SR) and Tumbleweed (TW).

I’m glad it works for you, honestly :hugs:

Same here, I use it every day to perform dup and switch into a new snapshot using atomic-update

Hi Karl,
Found your link and watched the vid. Excellent and makes it very clear. It will help me a great deal in these rapidly changing times!
Budge

Just to link to my earlier related post and taking your advice with bkupd.service I may need some help with that but if I can return to the OP question here I too have been thinking on where to go after Leap15.5 for my work machines. Malcolm and others have all mentioned MicroOS and Slowroll. To which should I move for these machines I ask? I do not have time to nurse these older machines too much and am not planning to change them any sooner than necessary but which way to go. Latest advice?

The roadmap still shows Leap 15.6 (in beta now) and Leap 16 in the future. If you’re happy with Leap, you could well stay with Leap. Beyond that, if you opt to change to MicroOS, Slowroll, or Tumbleweed, it ultimately comes down to your needs and personal preferences.

Understood and thanks. So I am staying with Leap for now. Just enjoying the conversations.