@non_space there should be no need to adjust priorities as vendor stickieness applies. Perhaps it was the split out of the individual lib packages which created this issue…
1 Like
I would not know the “why” of it . . . seems like there was a “migration” of packages away from Packman a month or two back, and now the return of the migrating birds back to the Packman??
This is a bold claim. From daily upgrades of infamous host erlangen:
erlangen:~ # journalctl -q -o short-monotonic -u dup -g 'packages to' | cut -d: -f2
17 packages to upgrade.
39 packages to upgrade.
82 packages to upgrade, 3 new.
7 packages to upgrade.
51 packages to upgrade.
11 packages to upgrade.
6 packages to upgrade.
59 packages to upgrade, 3 new, 3 to remove.
6 packages to upgrade.
7 packages to upgrade.
70 packages to upgrade, 2 new.
8 packages to upgrade.
112 packages to upgrade.
119 packages to upgrade.
91 packages to upgrade, 1 new.
118 packages to upgrade.
60 packages to upgrade.
60 packages to upgrade.
28 packages to upgrade, 1 to downgrade.
6 packages to upgrade.
100 packages to upgrade, 1 new.
3 packages to upgrade.
136 packages to upgrade.
30 packages to upgrade.
17 packages to upgrade.
144 packages to upgrade.
51 packages to upgrade.
299 packages to upgrade.
23 packages to upgrade.
36 packages to upgrade, 5 new, 5 to remove.
36 packages to upgrade, 1 new.
8 packages to upgrade.
6 packages to upgrade.
19 packages to upgrade, 2 to change vendor.
10 packages to upgrade.
135 packages to upgrade, 15 new, 15 to remove.
230 packages to upgrade.
15 packages to upgrade.
2 packages to upgrade.
15 packages to upgrade.
234 packages to upgrade, 19 new, 19 to remove.
92 packages to upgrade, 2 new, 1 to remove.
256 packages to upgrade, 2 new.
87 packages to upgrade.
14 packages to upgrade.
11 packages to upgrade.
39 packages to upgrade, 1 to change arch.
42 packages to upgrade.
43 packages to upgrade, 1 new.
erlangen:~ #
With proper configuration of zypper no substantial migration is observed since 19. November:
erlangen:~ # journalctl -q -o short-monotonic -u dup -g 'packages to' | cut -d: -f2|grep change
19 packages to upgrade, 2 to change vendor.
39 packages to upgrade, 1 to change arch.
erlangen:~ #
You may want to log commands issued and actions performed by zypper. I am waiting for factual claims.
1 Like
But you understand that your machines are not the benchmark for other real world setups? That means, other users may use not the same amount of packages from packman as you . Or they use the full packman and not only essentials. Or they are more experienced than you and only use some packages of packman and know how to deal properly with only a subset of packages…
Common sense says that there are countless more possible setups than yours avialable in the world…
4 Likes
@karlmistelberger what factual information is needed? Lets be very clear, I don’t use packman, I do have my own custom builds, in a local repository.
The question is why would you blindly go ahead and update a Tumbleweed system (daily?) without review, transactional-update system sure as it will auto rollback.
The system is telling you something is amiss and needs human input, in this case it’s just the build workflow between packman and Factory, Factory and Tumbleweed, it has no bearing on zypper priorities aside from masking the real issue as to why it occured…
Zypper has improved over the years, priorities are a thing of the past…
1 Like
et al:
All, or most, constructive opinions are welcomed by the OP . . . . In this recent migration case, unfortunately I didn’t copy/paste the data, but unlike Karl’s case of only two packages changing vendors I believe after running the from Packman Repo allow change command there were 17 packages listed as changing, to, or back to Packman. So, in theory, that could have meant 17 inquiries to negotiate before zypper would run through??
That still is a lot of “human” input asked by zypper, before allowing regular upgrading to go through . . . . I contrast that with my experience in the Sidster, where running an apt dist-upgrade will sometime bring a console window that opens that has one item of note to mention as a possible need for attention . . . if I q key out of it, apt moves forward . . . HAL9000 does not need my pesky humanity to mull over package changes . . . HAL9000 handles it for the most part. TW used to be that way, now fading into the disappearing past . . . now needing more and more attention from the human handler . . . questions, so many questions . . . . : - 0
@non_space The problem is the lack of staging on packman, use requires human intervention at points in time, in this case it doesn’t matter which way they go it will always be out of sync, using factory is the lesser of two evils as it will get built/synced in most cases before a snapshot release (which if delayed causes issues as well). If they use Tumbleweed, the snapshot gets released, then Packman starts to build, Packman also lacks any build power, they have two hosts with 4 workers for x86_64, so it will take time for packages to to build and sync out to the repos, which would lead to longer disruptions.
Bear in mind, how other distros package is up to them and not a good comparison how openSUSE deals with things like patent encumbered, proprietary packages, follow upstream closely etc.
1 Like
I understand that there is human effort involved in bringing an OS to fruition, I’m just responding as an “end user” of said offering, the amount of attention required to use one system versus another . . . more or less “dispassionately” in comparison to how I was ten years back when a system blew itself up, say for example . . . where “moral injury” was suffered as data was lost in a puff of cyber smoke . . . . Now I understand there is an element of “time” that gets pulled to keep an open source system going . . . but some seem to require more time and attention than others. One can ask whether those decisions are well spent, or just spent. TW provides a zippy platform, but that zip has of late taken large swathes of time for one reason or yet another . . . .
@non_space if your just an end user, then I would suggest flatpaks and distrobox which is how it rolls on MicroOS flavors… no Packman needed…
1 Like
That is all that I am . . . I’ll have to ask about how to check into that, when I get a free moment. Obviously that would involve the repos . . . .
@non_space adding flathub as your user and then installing flatpaks as your user…
On MicroOS I just run this user script;
cat bin/user_flatpaks
#!/usr/bin/bash
cd ~/
file="~/.flatpak_added"
if [ ! -f "$file" ]
then
echo "Creating flathub repo and adding flatpaks..."
# Add flathub repository as user
flatpak --user remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
# Install flatpak applications
flatpak --user install --noninteractive com.github.tchx84.Flatseal \
com.google.Chrome \
org.virt_manager.virt-viewer
touch ~/.flatpak_added
else
echo "Flathub and flatpaks already added as your user..."
fi
Flatseal is for permissions and configuration of each flatpak (or global options)…
Only install as your user, nothing is needed from a system wide perspective.
1 Like
Sorry, I am asking @non_space.
1 Like
Properly configured zypper, does an excellent job in upgrading the system. Most of the time it outperforms users.
OK, thanks for sharing that data . . . my Pop_OS machine uses flatpak?? it comes set up that way, and needs a separate command to add in the flathubs, which seems to be for chrome and some basic “freedesktop” system stuff . . . .
In this case these packages are added and then at some point Packman would be removed from the repo list or at least “deactivated” . . . and the various video codecs would then be handled by the flatpak package system???
I’ll check into it, now that Packman is there, and I now know how to -allow-all-changes . . . I might not have to make the change . . . but, could do . . . .
@non_space Correct, all the required codecs are installed as per the flatpak requirements and shared as well between applications if they are used elsewhere.
1 Like
In Pop! I have to run a command “flatpak update” possibly with sudo or not, to get the flathub stuff to run through.
Is that the same in TW, or those are added into the zypper handling, no extra commands needed for them to be run, just a regular “zypper dup”??
@non_space yes, all as your user flatpak --user update.
1 Like
This is so right. Basically anyone of us have a different setup. Take me for example: I barely use pacman essentials. Mostly in my system are main packages, some specific ones like Skype and CoreControl (which is great for AMD CPU&GPU users that are in need to create flexible profiles to specific software, even under Wine layer) and flatpaks. I love to play emulators and do some testing. All of them are under flatpak version included the editing video side. Yesterday, I had a blast playing Super Mario Wonder on Yuzu.
This distro is fantastic. It requires only one thing: no prejudice.
Cheers
1 Like