I have been observing this in the last years, and sorry if I am a bit abrasive, but this is becoming more and more frustrating.
I use tumbleweed, and I regularly observe new packages when issuing zypper dup.
Now, I understand that often-times these are valid. But around every week-or-so I see some nonsense.
The one today: kernel-default recommends kernel-firmware whose info says
Installed Size : 855.5 MiB
Installed : No
Status : not installed
Source package : kernel-firmware-20230707-1.1.src
Upstream URL : https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
Summary : Linux kernel firmware files
Description :
This package contains the raw uncompressed firmware files for Linux kernel
drivers. This package is provided only for compatibility with older kernels
that do not support the compressed format.
So, this is a deprecated form of kernel-firmware distribution, which takes up 855.5 MB, and would silently creep up on my system.
This kind of continuos bloating reminds me of another OS from Redmond. Installing recommends when (d)uping is the default, and it has its benefits that makes turning that off not-optimal. However, continuously examining every recommended new package in a rolling-release distro is sort of unrealistic.
Help me escalate this problem, as package maintainers needs some serious disciplining.
Every new recommends entry needs some serious, not-just-stamp-as-they-come-in reviewing.
I opened some specific issue in bugzilla, but at this point I feel like it would be fighting windmills doing that for every new crappy recommended package.
But allow me to express: I am grateful for OpenSUSE as a whole, I just see this specific, and quite major problem and I want to help eliminate it.
I said, turning off recommends globally is too drastic.
I have 79 zypper locks on a workstation (from which many are wildcards, like subversion*), but adding a new one to that every month is kinda indication of a systematic problem. For which I am trying to raise some attention.
But maybe I am missing something - what fine-tuning do you have in mind?
The only configuration option is to disable recommends and OP already said that âturning off recommends globally is too drasticâ so OP is aware of it and does not want it. OP also does not want to fix it for âevery new crappy recommended packageâ. This is usual wish for the mind reading computers. While discussing it may be entertaining, there is nothing that can be done from technical side. We on this forum certainly cannot escalate anything and have no influence on package maintainers and even we had it would still be non-technical topic.
Recommendations are creeping in which are way too generic, or even installing frankly obsolete packages like the one in my original post. Saying that I want mind-reading if I donât want obsolete packages, mailserver installed because I have a database (something like that, I canât remember the specific mailserver recommender on a striclty dev workstation) is frandly strawmaning my argument, which is: not enough care is done in package configuration.
I also said Iâve opened specific issues.
I am aware that maybe this is not the place to raise this issue.
Although thank for clarifying that nobody here can help, I guess a direction, a pointer for a better place to further discussion is too much to ask.
Maybe you missunderstood the whole concept of openSUSE Tumbleweed. Tumbleweed gives the administrator full power to adapt the system to its needs. This includes that a vast amount of packages is available and also recommended so that you have a base system with nearly endless possibilities to work with or adapt it. So if this is nothing what you need or want, maybe a powerfull rolling release is the wrong solution for you.
Tumbleweed empowers you with full control over your system, letting you define the settings you want and be done with it. No longer do you have to worry about a system interfering with your workflow.
Tumbleweed builds on decades of usage, testing and debugging by hundreds of power-users, developers, system administrators and demanding doers that cannot afford to jeopardize their workflow. Tumbleweedâs solidity is embodied in many core packages whose DNA stems from the venerable SUSE Linux Enterprise Server.
Talking about it isnât likely to accomplish anything. This isnât how openSUSE works.
If you want something in openSUSE to change?
Then do it. Everything is developed in the open, and open to contribution, and most of the maintainers and developers are also the same people that use the software, and do what they do, because of that. Nobody is being assigned or paid to do anything in this distribution.
If you donât like the way that something is done? Head to OBS, branch the package youâre concerned with, fix whatever issue it is thatâs bugging you, and submit your fixes.
I canât guarantee that the existing maintainers are going to accept your changes, but then again, they might.
I considered this discussion over, and was willing to head to OBS and fork the package (which I have done before), and most importantly, contribute my fixes.
And I will do that, regardless of the condescending tune.
Iâve been using OpenSUSE about 10 years ago, switched to Tumbleweed on my main workstation 7 years ago, using Leap on my (and company) servers.
I donât need high-horse things that that do no real justice, especially when to issue is clear:
The package recommended with the default, fresh kernel says about itself this - to repeat.
This package is provided only for compatibility with older kernels
that do not support the compressed format.
If you think this is empowerment of users, then - I will be polite, and stop here.
I will just do that.
But as the systemd unit hardening issue, there are efforts escalated to more than one people.
I guess Iâll have to fix as many as I can.
zypper search -x --provides kernel-firmware may be educational. On my NET image installation in December 2022 kernel-firmware was not installed. DVD does not include kernel-firmware either.
Itâs not just recommends that is nonsense. Requires can be at least as annoying:
# rpm -qa | grep fonts | sort
agfa-fonts-2003.03.19-94.noarch
dejavu-fonts-2.37-1.19.noarch
fonts-config-20200609+git0.42e2b1b-1.12.noarch
ghostscript-fonts-std-9.06-13.13.noarch
google-droid-fonts-20121204-8.5.noarch
liberation-fonts-2.1.5-1.6.noarch
linux-libertine-fonts-5.3.0-8.22.noarch
mkfontscale-1.2.2-1.6.x86_64
xorg-x11-fonts-7.6-45.1.noarch
xorg-x11-fonts-core-7.6-45.1.noarch
# zypper ll | grep font
8 | adobe-sourc*fonts | package | (any) |
9 | agfa-fonts | package | (any) |
14 | cantarell-font* | package | (any) |
20 | google*fonts | package | (any) |
25 | intlfonts* | package | (any) |
48 | raleway-font* | package | (any) |
# inxi -G
Graphics:
Device-1: AMD RV620 PRO [Radeon HD 3470] driver: radeon v: kernel
Display: server: X.org v: 1.21.1.8 driver: X: loaded: modesetting
unloaded: fbdev,vesa gpu: radeon resolution: 1: 2560x1440 2: 1680x1050
API: OpenGL Message: GL data unavailable for root.
big31:~ # time zypper -v dup
...
Computing upgrade...
7 Problems:
Problem: the to be installed kdebase3-SuSE-11.3-105.22.x86_64 requires 'kdebase3-SuSE-lang', but this requirement cannot be provided
Problem: the to be installed Mesa-dri-23.1.3-353.1.x86_64 requires 'libdrm_intel.so.1()(64bit)', but this requirement cannot be provided
Problem: the to be installed Mesa-gallium-23.1.3-353.1.x86_64 requires 'libdrm_nouveau.so.2()(64bit)', but this requirement cannot be provided
Problem: the to be installed gtk3-metatheme-adwaita-3.28-1.22.noarch requires 'cantarell-fonts', but this requirement cannot be provided
Problem: the to be installed yast2-qt-branding-openSUSE-84.87.20230227-1.3.noarch requires 'adobe-sourcesans3-fonts', but this requirement cannot be provided
Problem: the to be installed yast2-theme-4.6.0-1.2.noarch requires 'google-poppins-fonts', but this requirement cannot be provided
Problem: the to be installed kde3-kipi-plugins-0.1.6-44.18.x86_64 requires 'libgpod.so.4()(64bit)', but this requirement cannot be provided
...
Problem: the to be installed kde3-kipi-plugins-0.1.6-44.18.x86_64 requires 'libgpod.so.4()(64bit)', but this requirement cannot be provided
not installable providers: libgpod4-0.8.3-12.6.x86_64[OSS]
Solution 1: Following actions will be done:
remove lock to allow installation of libimobiledevice-1_0-6-1.3.0+179git.20230430-1.2.x86_64[OSS]
remove lock to allow installation of libimobiledevice-glue-1_0-0-1.0.0+git3.20230513-1.1.x86_64[OSS]
Solution 2: deinstallation of kde3-kipi-plugins-0.1.6-44.14.x86_64
Solution 3: keep obsolete kde3-kipi-plugins-0.1.6-44.14.x86_64
Solution 4: break kde3-kipi-plugins-0.1.6-44.18.x86_64 by ignoring some of its dependencies
...
Why are drm both separately packaged and all required to be installed together when all could be in one package if all brands are actually required to be installed for any of them to work?
Why do I need to please multiple sets of designer whims by including their separate choices of fonts on my machines in addition to those I prefer, which I must specially configure in order to actually ever see used?
Lang? The software is written in English. No extra âlangâ package should be required to use it.
All those cases are just some of the routine here, many âbrokenâ packages that work perfectly in their âbrokenâ state.
Separate packages for separate brand technologies are understandable. What I cannot fathom is why an Intel GPU with libdrm_intel1 installed ârequiresâ amdgpu, nouveau and radeon drm packages too, or why an AMD GPU with libdrm_amdgpu1 installed ârequiresâ intel and nouveau drm packages too, or why an NVidia GPU with libdrm_nouveau2 installed ârequiresâ amdgpu, intel and radeon drm packages too.
Anyway, you may follow the recommendations or ignore them. Some information from infamous host erlangen:
Host is up to date:
erlangen:~ # zypper -n dup -D
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
Nothing to do.
erlangen:~ #
Package kernel-firmware is NOT installed:
erlangen:~ # zypper info kernel-firmware
Loading repository data...
Reading installed packages...
Information for package kernel-firmware:
----------------------------------------
Repository : Haupt-Repository (OSS)
Name : kernel-firmware
Version : 20230707-1.1
Arch : noarch
Vendor : openSUSE
Installed Size : 855.5 MiB
Installed : No
Status : not installed
Source package : kernel-firmware-20230707-1.1.src
Upstream URL : https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/
Summary : Linux kernel firmware files
Description :
This package contains the raw uncompressed firmware files for Linux kernel
drivers. This package is provided only for compatibility with older kernels
that do not support the compressed format.
erlangen:~ #
An experienced programmer might see an explanation there somewhere, but not me. That said, I put it to the test. For an old Radeon HD3470, without libdrm_intel1 and libdrm_nouveau2 installed, I was getting the following from inxi -Gaz:
Thatâs nice. kernel-firmware-all and kernel-firmware provides kernel-firmware, which is - as stated before - is a recommendation of default kernel.
So if you uninstall kernel-firmware-all - which by the way, should be a pattern, instead of a metapackage with two docs? - beacause, than you get instead close to a GB of stuff on your next dup (again: default settings).
Very nice indeed
Next todo: confirm same for Intel and NVidia GPUs, but itâs already past bedtimeâŚ