[ADVICE] In some cases zypper should not install the recommended packages.
Hi! I'm Poplar, a Tumbleweed user. I suggested that zypper should stop automatically installing recommended packages when it detects that a specific package is already installed. When I updated my system, zypper automatically added chromium to the list of software to be installed in one of the updates. However, I had already installed google-chrome from google's repositories. zypper keeps trying to install the recommended alternative package for the user when it doesn't detect the browser rpm package from the official openSUSE repositories. In order to prevent zypper from installing chromium as a replacement for firefox (which I uninstalled), I had to use the zypper al command to lock several packages in a row to stop zypper from recommending alternatives once and for all. The locked packages were: w3m, seamonkey, lynx, links, libdisplay-info-tools, firefox-esr, falkon and elinks. I don't think it's a reasonable action for zypper to continue to push alternative recommended packages to users when a specific package (such as chrome) is already installed via zypper just because it's not in the openSUSE repositories and the official list of recommended packages. Sincerely, Poplar.at.twilight
On 2025-03-09 18:01, Poplar.at.twilight wrote:
The normal thing to do is to install firefox, and then chrome. If you do not want to install firefox because it is big, then install any of the text alternatives: w3m, lynx, links... They are tiny. Your way you will also have problems when clicking a link on email, the system will not be able to open any browser. -- Cheers / Saludos, Carlos E. R. (from 15.6 x86_64 at Telcontar)
Hi, Thanks for your suggestion. My current solution is to remove and lock all recommended browser packages. I don't want these never-to-be-used packages to be actively introduced to my computer. The issue was triggered by zypper's algorithm, so I shared it on the factory mailing list instead of the openSUSE forums as a feedback. I'm not sure what changes would need to be made to the code to make zypper stop pushing recommended packages of the same type to users once it detects a user-installed, non-official source rpm package. But I think it's important to say something about this so that developers can at least see what's happening in the end-use scenario. Sincerely, Poplar.at.twilight
et al This is an interesting thread, providing feedback on zypper from the end user's experience. As another end user I find zypper to be at once "very powerful," but also "obtuse" or perhaps tone deaf might be a similar metaphor. In my case the feedback would be about zypper's installation of kernels that may OR may not be compatible with the hardware that TW is installed on . . . OR maniacally installing packages that seem to break basic function of the system. In my case the last kernel that reliably revived the display in TW was 6.12.6. In the last few days my other linux installs have moved their kernels past that to 6.12.12 & 6.12.17 in Trixie and Sid and apt maintains the system such that the display will awaken from suspend . . . but zypper is providing kernels or packages which are not???? Same "Old" machine, etc. In my experience with TW now extending back in quite a few years, zypper has of late been installing kernels that do not revive my display after suspending. Comments on the forum post from admin/guru's have suggested, "old hardware" as the source of the problem, but zypper blithely continues to install new kernels and new packages. So the question remains, is it really an "old hardware" problem OR is zypper a "zombie machine" that is not paying attention to where it is installing into?? The latest 6.13.5 kernel has returned some intermittent revival of the display, but not consistently, so a newer kernel may fix the issue this time, or it may not? The issue has recurred around the nvidia card, where using nouveau did not prevent installing some proprietary software, that then locked nouveau out and resulting in this recurring failure to revive the display problem . . . which seems to show up every 6 months or so, or after a large number of package upgrades . . . that zypper installs. So zypper does not appear to able to discern the results of its upgrades on a functioning system, which has resulted in . . . non-function, which zypper does not recognize that it has done. Bug report has been filed . . . languishing in with others, against the kernel, but perhaps this is a **zypper** problem that should be reviewed by the zypper team? https://forums.opensuse.org/t/after-zypper-dup-in-tw-for-2082-packages-today... There was a time now fading into the past where TW's package upgrades were reliable as a stone axe, now in the last 4 some years zypper will provide "wild card" outcomes . . . my "Sid" install in comparison is "rock solid." F
Hi Poplar, Am 09.03.25 um 21:41 schrieb Poplar.at.twilight:
you could try if "zypper al web_browser" would be good enough (remove all other locks, then try again). All these packages provide "web_browser". I guess that *some* pattern you have installed recommends web_browser. In my case it is ~> rpm -q --whatrecommends web_browser patterns-base-x11_enhanced-20241218-3.1.x86_64 it might also be enough if you just remove the pattern package that recommends it.
The issue was triggered by zypper's algorithm, so I shared it on the factory mailing list instead of the openSUSE forums as a feedback.
It's not really zyppers algorithm, it's the metadata of the installed packages.
I'm not sure what changes would need to be made to the code to make zypper stop pushing recommended packages of the same type to users once it detects a user-installed, non-official source rpm package. But I think it's important to say something about this so that developers can at least see what's happening in the end-use scenario.
You can always set the "--no-recommends" switch somewhere in the zypper config (sorry, don't know the exact place, my muscle memory has just been trained to always use --no-recommends on everything zypper involving installaton, including "patch", "install", "dup", ... ;-) The thing is, that these recommendations (even though *I personally* do disregard them to get a leaner system) are there for a reason: to provide a polished experience to the average user, without them having to sort out why certain kinds of files don't open or display after a default installation etc. Your usecase is at least as special as mine, so you probably need to tune the system slightly. And as you are concerned about a 2MB package like w3m wasting precious resources on your installation, I'd guess that you are totally in the market for "--no-recommends" anyway :-) For now, I'd really go for (in that order): * back up and then remove your existing locks * find out what recommends web_browser and remove that if possible * add a lock on "web_browser" Only if all this does not help / is not feasible, then maintain your extensive list of locks. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Patrick Schaaf composed on 2025-03-10 12:47 (UTC+0100):
Stefan Seyfried wrote:
I wonder if there's any functional difference between that and what I've had configured for many years:
grep yReq /etc/zypp/zypp.conf solver.onlyRequires = true
-- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On Mon, 10 Mar 2025, 14:28:48 +0100, Felix Miata wrote:
As I'm paranoid about this beast, I have always set it at both locations ;-) I *guess*, the setting in /etc/zypp/zypp.conf is closely related with libzypp (dunno which program might link with it, though), while the one in /etc/zypp/zypper.conf directly controls the behaviour of the "zypper" command itself. Cheers. l8er manfred
On 2025-03-09 18:01, Poplar.at.twilight wrote:
The normal thing to do is to install firefox, and then chrome. If you do not want to install firefox because it is big, then install any of the text alternatives: w3m, lynx, links... They are tiny. Your way you will also have problems when clicking a link on email, the system will not be able to open any browser. -- Cheers / Saludos, Carlos E. R. (from 15.6 x86_64 at Telcontar)
Hi, Thanks for your suggestion. My current solution is to remove and lock all recommended browser packages. I don't want these never-to-be-used packages to be actively introduced to my computer. The issue was triggered by zypper's algorithm, so I shared it on the factory mailing list instead of the openSUSE forums as a feedback. I'm not sure what changes would need to be made to the code to make zypper stop pushing recommended packages of the same type to users once it detects a user-installed, non-official source rpm package. But I think it's important to say something about this so that developers can at least see what's happening in the end-use scenario. Sincerely, Poplar.at.twilight
et al This is an interesting thread, providing feedback on zypper from the end user's experience. As another end user I find zypper to be at once "very powerful," but also "obtuse" or perhaps tone deaf might be a similar metaphor. In my case the feedback would be about zypper's installation of kernels that may OR may not be compatible with the hardware that TW is installed on . . . OR maniacally installing packages that seem to break basic function of the system. In my case the last kernel that reliably revived the display in TW was 6.12.6. In the last few days my other linux installs have moved their kernels past that to 6.12.12 & 6.12.17 in Trixie and Sid and apt maintains the system such that the display will awaken from suspend . . . but zypper is providing kernels or packages which are not???? Same "Old" machine, etc. In my experience with TW now extending back in quite a few years, zypper has of late been installing kernels that do not revive my display after suspending. Comments on the forum post from admin/guru's have suggested, "old hardware" as the source of the problem, but zypper blithely continues to install new kernels and new packages. So the question remains, is it really an "old hardware" problem OR is zypper a "zombie machine" that is not paying attention to where it is installing into?? The latest 6.13.5 kernel has returned some intermittent revival of the display, but not consistently, so a newer kernel may fix the issue this time, or it may not? The issue has recurred around the nvidia card, where using nouveau did not prevent installing some proprietary software, that then locked nouveau out and resulting in this recurring failure to revive the display problem . . . which seems to show up every 6 months or so, or after a large number of package upgrades . . . that zypper installs. So zypper does not appear to able to discern the results of its upgrades on a functioning system, which has resulted in . . . non-function, which zypper does not recognize that it has done. Bug report has been filed . . . languishing in with others, against the kernel, but perhaps this is a **zypper** problem that should be reviewed by the zypper team? https://forums.opensuse.org/t/after-zypper-dup-in-tw-for-2082-packages-today... There was a time now fading into the past where TW's package upgrades were reliable as a stone axe, now in the last 4 some years zypper will provide "wild card" outcomes . . . my "Sid" install in comparison is "rock solid." F
Hi Poplar, Am 09.03.25 um 21:41 schrieb Poplar.at.twilight:
you could try if "zypper al web_browser" would be good enough (remove all other locks, then try again). All these packages provide "web_browser". I guess that *some* pattern you have installed recommends web_browser. In my case it is ~> rpm -q --whatrecommends web_browser patterns-base-x11_enhanced-20241218-3.1.x86_64 it might also be enough if you just remove the pattern package that recommends it.
The issue was triggered by zypper's algorithm, so I shared it on the factory mailing list instead of the openSUSE forums as a feedback.
It's not really zyppers algorithm, it's the metadata of the installed packages.
I'm not sure what changes would need to be made to the code to make zypper stop pushing recommended packages of the same type to users once it detects a user-installed, non-official source rpm package. But I think it's important to say something about this so that developers can at least see what's happening in the end-use scenario.
You can always set the "--no-recommends" switch somewhere in the zypper config (sorry, don't know the exact place, my muscle memory has just been trained to always use --no-recommends on everything zypper involving installaton, including "patch", "install", "dup", ... ;-) The thing is, that these recommendations (even though *I personally* do disregard them to get a leaner system) are there for a reason: to provide a polished experience to the average user, without them having to sort out why certain kinds of files don't open or display after a default installation etc. Your usecase is at least as special as mine, so you probably need to tune the system slightly. And as you are concerned about a 2MB package like w3m wasting precious resources on your installation, I'd guess that you are totally in the market for "--no-recommends" anyway :-) For now, I'd really go for (in that order): * back up and then remove your existing locks * find out what recommends web_browser and remove that if possible * add a lock on "web_browser" Only if all this does not help / is not feasible, then maintain your extensive list of locks. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
participants (9)
-
Andrei Borzenkov -
Carlos E. R. -
Felix Miata -
Fritz Hudnut -
Knurpht-openSUSE -
Manfred Hollstein -
Patrick Schaaf -
Poplar.at.twilight -
Stefan Seyfried