What you say is not related to what I said. Flatpaks can be installed system wide by the system manager, they still run sandboxed from the rest of the system. Please read up, and stop arguing and nitpicking.
OK, it seems that my conclusion from above was incorrect. I only tried to understand this talking about Flatpak in relation to the “Packman outdated yes or no” question.
Is a way to do it. If you use flatpak, don’t need Packman.
I don’t understand. “Adding Packman” does nothing per se, so you can “add a repo” whenever you want.
Then consider “vendor stickiness”, so an app with Vendor=openSUSE installed from OSS will remain with OSS and update from OSS even if there are other versions in Packman (with Vendor=http://packman.links2linux.de) until you ask the system to --allow-vendor-change.
Often though apps from OSS require (some) dependencies from OSS and apps from Packman require (some) dependencies from Packman, so you cannot mix and match at will. For instance you cannot install ffmpeg-7 from Packman and libavcodec61 from OSS.
Despite all the different views - I find this a most interesting thread. GNU/Linux is changing with time, as is openSUSE, and I find it interesting to try and stay ‘with the change’. That does not mean I succeed but it is interesting.
Thankyou to all for your opinions on this.
- Lots of packages are available in Packman which aren’t needed.
- Users may want to perform a vendor switch to Packman.
- Using the Packman versions results in enhanced capabilities and performance.
- Users may refrain from installing additional packages as recommended by numerous tutorials.
I minimize hassle with Packman by installing only those codecs which are already available in https://cdn.opensuse.org/tumbleweed/repo/oss/:
erlangen:~ # zypper se -is --repo Packman
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+---------------------------+---------+-----------------------------------------+--------+-----------
i | ffmpeg-7 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libavcodec58_134 | package | 4.4.6-1699.12.pm.10 | x86_64 | Packman
i | libavcodec60 | package | 6.1.2-1699.9.pm.17 | x86_64 | Packman
i | libavcodec61 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libavdevice61 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libavfilter10 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libavformat58_76 | package | 4.4.6-1699.12.pm.10 | x86_64 | Packman
i | libavformat61 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libavutil56_70 | package | 4.4.6-1699.12.pm.10 | x86_64 | Packman
i | libavutil58 | package | 6.1.2-1699.9.pm.17 | x86_64 | Packman
i | libavutil59 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libfdk-aac2 | package | 2.0.2-1699.1.pm.139 | x86_64 | Packman
i | libgbm1 | package | 25.1.7-1699.422.pm.3 | x86_64 | Packman
i | libheif-aom | package | 1.20.2-1699.4.pm.1 | x86_64 | Packman
i | libheif1 | package | 1.20.2-1699.4.pm.1 | x86_64 | Packman
i | libpostproc55_9 | package | 4.4.6-1699.12.pm.10 | x86_64 | Packman
i | libpostproc58 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libquicktime0 | package | 1.2.4+git20180804.fff99cd-1699.11.pm.4 | x86_64 | Packman
i | librtmp1 | package | 2.4.20151223.fa8646d-1699.2.pm.20 | x86_64 | Packman
i | libswresample3_9 | package | 4.4.6-1699.12.pm.10 | x86_64 | Packman
i | libswresample4 | package | 6.1.2-1699.9.pm.17 | x86_64 | Packman
i | libswresample5 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libswscale5_9 | package | 4.4.6-1699.12.pm.10 | x86_64 | Packman
i | libswscale8 | package | 7.1.1-1699.10.pm.4 | x86_64 | Packman
i | libvdpau_r600 | package | 25.1.7-1699.422.pm.4 | x86_64 | Packman
i | libvdpau_radeonsi | package | 25.1.7-1699.422.pm.4 | x86_64 | Packman
i | libvlc5 | package | 3.0.21-1699.11.pm.3 | x86_64 | Packman
i | libvlccore9 | package | 3.0.21-1699.11.pm.3 | x86_64 | Packman
i | libvulkan_lvp | package | 25.1.7-1699.422.pm.4 | x86_64 | Packman
i | libx264-164 | package | 0.164+git20231001.31e19f92-1699.1.pm.21 | x86_64 | Packman
i | libx265-215 | package | 4.1-1699.3.pm.5 | x86_64 | Packman
i | Mesa | package | 25.1.7-1699.422.pm.3 | x86_64 | Packman
i | Mesa-dri | package | 25.1.7-1699.422.pm.4 | x86_64 | Packman
i | Mesa-gallium | package | 25.1.7-1699.422.pm.4 | x86_64 | Packman
i | Mesa-libEGL1 | package | 25.1.7-1699.422.pm.3 | x86_64 | Packman
i | Mesa-libGL1 | package | 25.1.7-1699.422.pm.3 | x86_64 | Packman
i+ | Mesa-libva | package | 25.1.7-1699.422.pm.4 | x86_64 | Packman
i | Mesa-vulkan-device-select | package | 25.1.7-1699.422.pm.4 | x86_64 | Packman
i+ | vlc | package | 3.0.21-1699.11.pm.3 | x86_64 | Packman
i | vlc-lang | package | 3.0.21-1699.11.pm.3 | noarch | Packman
i | vlc-noX | package | 3.0.21-1699.11.pm.3 | x86_64 | Packman
i | vlc-qt | package | 3.0.21-1699.11.pm.3 | x86_64 | Packman
erlangen:~ #
Sorry, was an expression, of course, if you add a repo is to use the software it contains.
Yes, but as you know there is a set of common libs and time to time you can see the question: install package1 needs file but this can’t be provided. 1 install package from oss-update that replaces package from packman, 2 keep package, 3 break dependencies
So in every upgrade (Tumbleweed/Slowroll) you can answer this 1, 2, 5, 10… times.
Most people uses systems (even Linux) with automatic update or at least silent upgrade. But openSUSE can’t do it this way.
Maybe, but TW/SR fails in this, every upgrade shows problems here.
Then you have blindly performed the vendor switch of all available packages to packman. As outlined now by different ppl, you don’t need to switch all packages to packman. This is even described in the SDB. If you don’t have ancient AMD HW, there is absolutely no need to switch the Mesa packages to packman. Mesa packages are the main factor of breakage, as they don’t undergo any Packman QA. The packman packages show up earlier in the repos whilst the dependencies from the official openSUSE repos need some time to undergo QA and therefore need some time to show up in the repos. This is when the dependency issues show up. A pure packman problem.
As already said, only switch needed packages to packman. What is needed, depends on your HW and codec needs. This helps to reduce dependency issues caused by packman.
Yes, but how I can say to zypper “upgrade these codecs but don’t ugrade mesa”?
Did you have a look at the SDB?
https://en.opensuse.org/SDB:Installing_codecs_from_Packman_repositories#Option_2:_Zypper
Yes, sudo opi codecs
Btw, what is the sense of a command saying “codecs” but installing more things?
Not here:
LT-B:~ # zypper --no-refresh up -r 14
Loading repository data...
Reading installed packages...
The following 4 items are locked and will not be changed by any action:
Available:
b43legacy-firmware iscan-firmware rtl8761b-firmware
Installed:
master-pdf-editor
The following 22 package updates will NOT be installed:
deadbeef gdk-pixbuf-loader-libheif libfdk-aac2 libgbm1 libheif1 libheif-aom libheif-dav1d libheif-ffmpeg libheif-jpeg libheif-openjpeg libheif-rav1e libheif-svtenc libquicktime0 libvulkan_intel libvulkan_lvp
Mesa Mesa-dri Mesa-gallium Mesa-libEGL1 Mesa-libGL1 Mesa-libva Mesa-vulkan-device-select
The following 9 packages are going to be upgraded:
ffmpeg-7 libavcodec61 libavdevice61 libavfilter10 libavformat61 libavutil59 libpostproc58 libswresample5 libswscale8
9 packages to upgrade.
Package download size: 10,4 MiB
Package install size change:
| 24,9 MiB required by packages that will be installed
0 B | - 24,9 MiB released by packages that will be removed
Backend: classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y):
I have installed ffmpeg-7 and its “requires” from Packman but not other packages that are available there. Please note the:
The following 22 package updates will NOT be installed:
That is because of “vendor stickiness”: those packages are installed from OSS and will not be updated from Packman even if a “higher” version appears on Packman.
As you see, just an information to remind me of that setting and no conflict or answer needed.
Maybe you have to reconsider what you have installed (and we are here to help if needed).
Sometimes it helps to read the linked part of the SDB. The zypper part…
But i made some adaptions to the SDB to make it more present by adding warnings.
Sidenote: It should already be common knowledge that using OPI can be harmfull to your system and should only be used with proper knowledge (i stumbled also over an ongoing discussion between the devs to remove it as it possibly violates licenses…).
Yes, but still opi is the first way recommended.
I’ve made sure the mesas are from OSS, okay.
But that doesn’t fix it when a Packman package pushes that update, right?
This article says differently.
Thanks for pointing out. I will shift the informations to the codec wiki to prevent further duplication and inconsistencies.
In the option 2: zypper, maybe is better to aim first to install only the codecs.
Thanks. Done…
1 Like
What package “pushes” a Mesa update from Packman? Or am I misunderstanding?
I don’t know, that is why I ask.