In most cases when zupper dup installs a newer version of a program or library it removes the older version but I know that is not always 100% true. I installed some of the development patterns when I built my system because I need to recompile the vmware modules. I noticed that as TW has moved from gcc 10 to 11 and now 12 that the old versions are also still installed. I'm guessing that is not a bug, but if it is let me know and I will submit a bug report. Is there any documentation or guidelines as to when zypper dup will not remove old versions when it installs a new version? Thanks!
On 12.06.2022 04:04, Joe Salmeri wrote:
In most cases when zupper dup installs a newer version of a program or library it removes the older version but I know that is not always 100% true.
zypper does equivalent of "rpm --upgrade", which replaces old package version with new package version. Technically RPM first installs new version and then removes old version. This *always* happens on installation on any package by zypper with the only exception being kernel (or in general other packages covered by "multiversion" configuration).
I installed some of the development patterns when I built my system because I need to recompile the vmware modules.
I noticed that as TW has moved from gcc 10 to 11 and now 12 that the old versions are also still installed.
gcc10, gc11 and gcc12 are three different packages and can be installed side by side. gcc12 is not new version of gcc10.
I'm guessing that is not a bug, but if it is let me know and I will submit a bug report.
Is there any documentation or guidelines as to when zypper dup will not remove old versions when it installs a new version?
As already mentioned, packages that match multiversion configuration.
Hi Andrei,
This *always* happens on installation on any package by zypper >> with the only exception being kernel (or in general other packages covered by "multiversion" configuration).
Right, I understand how this works for the kernel and actually have modified my /etc/zypp/zypp.conf to change the number of kernels kept. The docs indicate that other packages configured for multiversion support are configured in /etc/zypp/multiversion.d/ but there are no files in that directory. So where is multiversion configured for gcc, or better yet, how can I get a list of the packages that would be in your list of "other packages covered by "multiversion" configuration"? I always use zypper for package management but looking in yast software in Package Classification, in Multiversion Packages, the only packages I have installed that are in that category are the kernel so it too doesn't seem to know about gcc being multiversion.
gcc10, gc11 and gcc12 are three different packages and can be installed side by side. gcc12 is not new version of gcc10.
I am confused by your last sentence since they are versions 10, 11, and 12 of the GNU C Compiler. I understand that gcc12 is not a new version of gcc10 and instead is GNU C Compiler version 12.
As already mentioned, packages that match multiversion configuration.
So how does one identify those type packages? In the 2 places I checked I did not find any multiversion configuration for gcc or any other packages except the kernel. Equally important, how does one know when it is safe to remove the old versions? I understand for the kernel and I understand if I configured multiversion for some other package as I would know what versions I need but what about for other packages like the gcc versions? On a fresh TW install, if I install Base Development and C/C++ Development it is only installing gcc12, so that seems to imply that 10 and 11 could safely be removed from my current system unless I am missing something. Thanks!
On 12.06.2022 18:29, Joe Salmeri wrote:
gcc10, gc11 and gcc12 are three different packages and can be installed side by side. gcc12 is not new version of gcc10.
I am confused by your last sentence since they are versions 10, 11, and 12 of the GNU C Compiler.
You confuse software version with package version. gcc10, gcc11 and gcc12 are different *packages*. Whether they are built from consecutive versions of the same software is irrelevant from package management point of view.
Aha! Now that makes sense and that's why there is no multiversion configuration because they are separate packages. So the gcc11 and gcc12 packages were installed when TW moved to those compilers. That makes sense but how will the older packages ever be removed? Otherwise we end up with gcc10 through gccXX all installed. Is that a cleanup that zypper dup will "eventually" do or is that something I manually need to manage and remove? I have found a few packages in a similar situation with multiple versions in different packages. So trying to determine if those situations warrant a bug report? If the process is for manual removal, then it seems there should be a way to easily identify those cases.
On 12.06.22 18:30, Joe Salmeri wrote:
Aha! Now that makes sense and that's why there is no multiversion configuration because they are separate packages.
So the gcc11 and gcc12 packages were installed when TW moved to those compilers.
That makes sense but how will the older packages ever be removed? Otherwise we end up with gcc10 through gccXX all installed.
Is that a cleanup that zypper dup will "eventually" do or is that something I manually need to manage and remove?
Probably zypper dup will clean this up. But only if the packages are no longer available in Tumbleweed (and probably some magic configuration in some metapackage is done by the release team). Right now, gcc7, gcc10, gcc11 and gcc12 are all still available.
If the process is for manual removal, then it seems there should be a way to easily identify those cases.
"zypper pa --orphaned" might help. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Sunday 2022-06-12 21:39, Stefan Seyfried wrote:
On 12.06.22 18:30, Joe Salmeri wrote:
Is that a cleanup that zypper dup will "eventually" do or is that something I manually need to manage and remove?
Probably zypper dup will clean this up. But only if the packages are no longer available in Tumbleweed (and probably some magic configuration in some metapackage is done by the release team).
weakremover() is the name of the magic.
Thanks Stefan. I looked in the GUI at the orphaned and there were only 2 items and they are not related to the gcc stuff. Those 2 items were: libdav1d5 libx264-161 Interestingly if I do a zypper rm --dry-run libdav1d5 It says it will remove 92 packages and also the kde and kde_plasma patterns! Clearly something must be wrong because zypper search --requires libdav1d5 does not return any packages that require it. Wonder why it wants to remove all that stuff in nothing requires it? The libx264-161 package is related to VLC and I understand why that one is orphaned.
On 13.06.22 16:16, Joe Salmeri wrote:
zypper search --requires-pkg libdav1d5
I would expected --requires to work too but I tried --requires-pkg and it returned 3 items.
So since there are packages which require libdav1d5, why is it being reported as orphaned when I run
zypper packages --orphaned
because it is no longer available in any repo. These 3 packages would not be installable anymore. Most likely if you run a full update now, thesa 3 packages will be updated and then no longer require libdav1d5 but libdav1d6 instead. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 13.06.2022 17:16, Joe Salmeri wrote:
zypper search --requires-pkg libdav1d5
I would expected --requires to work too but I tried --requires-pkg and it returned 3 items.
RPM dependencies are between abstract strings that are Provided by one package and Required/Recommended/... by another package. "zypper search --requires foo" looks for packages Requiring literal string "foo". But package foo may Provide string "my-fancy-dependency-name" and package bar may Require string "my-fancy-dependency-name".
On Sun 2022-06-12, Stefan Seyfried wrote:
If the process is for manual removal, then it seems there should be a way to easily identify those cases. "zypper pa --orphaned" might help.
Those are packages not coming out of any of the currently active repositories, correct? How about zypper pa --unneeded The man page is ... pretty useless, sadly: --unneeded Show packages which are unneeded. Gerald
I am using tumbleweed-cli and am currently on build 20220606. libdavld5 does not appear in the 20220606 repos. zypper search -s says that the Repository is (System Packages). So it's not in the 20220606 repo, says it is orphaned, and yet if I try to remove it then it says it will remove 92 packages including the kde and kde_Plasma patterns. Seems odd to have such a big impact and be reported as orphaned???
Am 12.06.22 um 18:30 schrieb Joe Salmeri:
So the gcc11 and gcc12 packages were installed when TW moved to those compilers.
That makes sense but how will the older packages ever be removed? Otherwise we end up with gcc10 through gccXX all installed.
Is that a cleanup that zypper dup will "eventually" do or is that something I manually need to manage and remove?
I have found a few packages in a similar situation with multiple versions in different packages.
You can tell zypper to "clean dependencies on removal" (either on the command line or via /etc/zypp/zypp.conf), which will automatically remove packages that have been automatically installed, if they are no longer needed. Additionally, you'll need to have gcc installed via the metapackages "gcc", "gcc-c++", and so on. The versioned gcc packages (gccXX, gccXX-c++, ...) should then appear in /var/lib/zypp/AutoInstalled: $ grep ^gcc /var/lib/zypp/AutoInstalled gcc12 gcc12-32bit gcc12-c++ Then they should be removed if no longer required by other packages (such as gcc, or maybe others). However, I would recommend carefully reviewing removed packages when using this option, sometimes things might be removed that you actually want. Best regards, Aaron
Thanks Aaron. I searched to see if anything was installed that required the gcc10 or gcc11 and did not find anything and was able to successfully remove them without issue so that I now only have gcc12 installed
On 13.06.2022 00:22, Aaron Puchert wrote:
Am 12.06.22 um 18:30 schrieb Joe Salmeri:
So the gcc11 and gcc12 packages were installed when TW moved to those compilers.
That makes sense but how will the older packages ever be removed? Otherwise we end up with gcc10 through gccXX all installed.
Is that a cleanup that zypper dup will "eventually" do or is that something I manually need to manage and remove?
I have found a few packages in a similar situation with multiple versions in different packages.
You can tell zypper to "clean dependencies on removal" (either on the command line or via /etc/zypp/zypp.conf), which will automatically remove packages that have been automatically installed, if they are no longer needed. Additionally, you'll need to have gcc installed via the metapackages "gcc", "gcc-c++", and so on.
This will not help in this case. --clean-deps removes packages that become unneeded after removal of requested packages, not arbitrary unneeded packages. So 1. You install gcc that pulls in gcc11 2. You update gcc which now pulls in gcc12 gcc11 is already "unneeded". If you remove "gcc" then it will remove gcc12 (which will become unneeded), not gcc11. bor@tw:~> zypper packages --unneeded | grep gcc i | openSUSE-20170729-0 | gcc10 | 10.3.1+git2389-1.4 | x86_64 i | openSUSE-20170729-0 | gcc11 | 11.2.1+git1635-1.4 | x86_64 i | openSUSE-20170729-0 | libstdc++6-devel-gcc10 | 10.3.1+git2389-1.4 | x86_64 i | openSUSE-20170729-0 | libstdc++6-devel-gcc11 | 11.2.1+git1635-1.4 | x86_64 bor@tw:~> sudo zypper rm --clean-deps gcc Reading installed packages... Resolving package dependencies... The following 9 packages are going to be REMOVED: gcc gcc12 gettext-tools libasan8 libtsan2 patch rpm-build rpm-build-perl rpm-build-python 9 packages to remove.
The versioned gcc packages (gccXX, gccXX-c++, ...) should then appear in /var/lib/zypp/AutoInstalled:
$ grep ^gcc /var/lib/zypp/AutoInstalled gcc12 gcc12-32bit gcc12-c++
Then they should be removed if no longer required by other packages (such as gcc, or maybe others).
"Should be" as in "I wish they will be removed" or as in "why computer does not read my mind"?
However, I would recommend carefully reviewing removed packages when using this option, sometimes things might be removed that you actually want.
Best regards, Aaron
Andrei, that was a nice detailed explanation which seems to indicate that the older gcc10 and gcc11 packages would never be removed. If that is true, that seems like a bug/problem to me. At a minimum, it seems like there should be a way to easily identify packages that have that situation and suggest that the older packages can be manually removed vs requiring a review of all packages installed to find them. The same situation we are discussing regarding the gcc* packages appears to also be occurring with libLLVM* because I have the following all installed: libLLVM11 libLLVM11-32bit libLLVM12 libLLVM12-32bit libLLVM13 libLLVM13-32bit libLLVM14 libLLVM14-32bit In the case of the libLLVM* packages the consume almost 0.5 GB of disk space so all of these situations can start to quickly add up in space used. So is there a way to identify and cleanup these situations or do we need to monitor zypper pa --unneeded looking for the situation and then manually remove them?
Am 13.06.22 um 06:18 schrieb Andrei Borzenkov:
This will not help in this case. --clean-deps removes packages that become unneeded after removal of requested packages, not arbitrary unneeded packages.
Seems you're right, the flag is only available for "zypper remove".
"Should be" as in "I wish they will be removed" or as in "why computer does not read my mind"?
Well, wouldn't it make sense? A package becoming unneeded could be the trigger for its removal, whether it becomes unneeded through "zypper remove" or "zypper dup". So I think --clean-deps should also be available for "dup". There should probably be a separate flag in zypp.conf since solver.cleandepsOnRemove only refers to removal. So we could have solver.cleandepsOnUpgrade or similar to solver.upgradeRemoveDroppedPackages it could be called solver.upgradeRemoveUnneededPackages. Aaron
Agreed. As A.B. pointed out, the definition of "unneeded" is crucial. Assuming that user-installed (vs. automatically-installed) packages and their dependencies are excluded, some automatically-installed packages may have become directly useful, and desired to be kept, even though they are not needed anymore to support user-installed packages. If the user is presented with a list of packages to confirm for removal, will it be obvious just from the name, whether a package is now being used directly? If the user makes such a choice, can the status of the package then be changed from automatic to user-installed so that it will be protected in the future? -- Robert Webb On Monday, June 13, 2022, 04:42:14 PM PDT, Aaron Puchert <aaronpuchert@alice-dsl.net> wrote: [...] Well, wouldn't it make sense? A package becoming unneeded could be the trigger for its removal, whether it becomes unneeded through "zypper remove" or "zypper dup". So I think --clean-deps should also be available for "dup". There should probably be a separate flag in zypp.conf since solver.cleandepsOnRemove only refers to removal. So we could have solver.cleandepsOnUpgrade or similar to solver.upgradeRemoveDroppedPackages it could be called solver.upgradeRemoveUnneededPackages. Aaron
On 2022-06-14 03:09, Robert Webb wrote:
Agreed. As A.B. pointed out, the definition of "unneeded" is crucial. Assuming that user-installed (vs. automatically-installed) packages and their dependencies are excluded, some automatically-installed packages may have become directly useful, and desired to be kept, even though they are not needed anymore to support user-installed packages. If the user is presented with a list of packages to confirm for removal, will it be obvious just from the name, whether a package is now being used directly? If the user makes such a choice, can the status of the package then be changed from automatic to user-installed so that it will be protected in the future?
In the now long away past, YaST knew about manually installed packages and they would not be removed automatically. But, AFAIR, the feature gave problems and was removed. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
On Tuesday, June 14, 2022, 09:11:07 AM PDT, Carlos E. R. <robin.listas@telefonica.net> wrote:
In the now long away past, YaST knew about manually installed packages and they would not be removed automatically. But, AFAIR, the feature gave problems and was removed.
But zypper knows, and acts differently depending on it. From the zypper manual: Automatically installed packages Packages added by the dependency solver in order to resolve a user’s request are remembered as having been 'automatically installed'. They may later be removed, if no more user installed packages depend on them (e.g. by zypper remove --clean-deps). You can list only user installed packages by filtering for "i+" in the status column of a zypper search. -- Robert Webb
On 14.06.2022 02:41, Aaron Puchert wrote:
So I think --clean-deps should also be available for "dup". There should probably be a separate flag in zypp.conf since solver.cleandepsOnRemove only refers to removal. So we could have solver.cleandepsOnUpgrade or similar to solver.upgradeRemoveDroppedPackages it could be called solver.upgradeRemoveUnneededPackages.
Yes, that sounds sensible. Now someone just needs to submit feature request ... :)
Am 14.06.22 um 07:25 schrieb Andrei Borzenkov:
On 14.06.2022 02:41, Aaron Puchert wrote:
So I think --clean-deps should also be available for "dup". There should probably be a separate flag in zypp.conf since solver.cleandepsOnRemove only refers to removal. So we could have solver.cleandepsOnUpgrade or similar to solver.upgradeRemoveDroppedPackages it could be called solver.upgradeRemoveUnneededPackages.
Yes, that sounds sensible. Now someone just needs to submit feature request ... :)
Filed <https://github.com/openSUSE/zypper/issues/443>. Ran across some related earlier issues like <https://github.com/openSUSE/zypper/issues/89> ("Support for exposing /var/lib/zypp/AutoInstalled"), with a fix proposed in <https://github.com/openSUSE/zypper/pull/165>, and <https://github.com/openSUSE/zypper/issues/116> ("Command to clean out all unneeded autoinstalled dependencies"). Aaron
On 2022-06-12 17:29, Joe Salmeri wrote:
Hi Andrei,
gcc10, gc11 and gcc12 are three different packages and can be installed side by side. gcc12 is not new version of gcc10.
I am confused by your last sentence since they are versions 10, 11, and 12 of the GNU C Compiler. I understand that gcc12 is not a new version of gcc10 and instead is GNU C Compiler version 12.
Because "11", "12"... are not a version number, as far as "rpm" is concerned, but part of the name string. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
Hi Carlos, Thanks, I get the package vs version information. What is not clear is when those "older" packages which contain the older gcc versions will ever be cleaned up and removed? Is that something zypper dup will eventually do or is that that removal something I need to monitor and manually cleanup? Since I have found several packages besides gcc which fall into this situation, I'm trying to determine whether they all require action on my part or if zypper dup will eventually do it?
I'm pretty sure that when they are not available in the distribution any more, they will be removed. But of course, you can manually do it before then. KaiRo Joe Salmeri schrieb:
Hi Carlos,
Thanks, I get the package vs version information.
What is not clear is when those "older" packages which contain the older gcc versions will ever be cleaned up and removed?
Is that something zypper dup will eventually do or is that that removal something I need to monitor and manually cleanup?
Since I have found several packages besides gcc which fall into this situation, I'm trying to determine whether they all require action on my part or if zypper dup will eventually do it?
On 2022-06-12 18:54, Joe Salmeri wrote:
Hi Carlos,
Thanks, I get the package vs version information.
What is not clear is when those "older" packages which contain the older gcc versions will ever be cleaned up and removed?
I guess never.
Is that something zypper dup will eventually do or is that that removal something I need to monitor and manually cleanup?
Since I have found several packages besides gcc which fall into this situation, I'm trying to determine whether they all require action on my part or if zypper dup will eventually do it?
It is an interesting point. I don't know if it can be automated. You can try to remove them, and if something needs them, zypper will say so. -- Cheers / Saludos, Carlos E. R. (from Elesar, using openSUSE Leap 15.3)
For manual action in the general case, you could do: zypper packages --unneeded and then, converting that output to a <package_list>: zypper remove [--dry-run] [-y] [--clean-deps] <package_list> I don't know how to feed the result of the first command to the second. For this to happen automatically, it seems like zypper would need to be configured with something like that '--clean-deps' option. I would have expected that to be the default for automatically installed packages, like your Gcc versions. Question: Does the operation of the --clean-deps option depend on whether a package was automatically installed or not? The comment in the 'Automatically installed packages' section of the zypper manual implies that it does, but the description under 'remove' does not. -- Robert Webb On Sunday, June 12, 2022, 09:54:39 AM PDT, Joe Salmeri <jmscdba@gmail.com> wrote: [...] What is not clear is when those "older" packages which contain the older gcc versions will ever be cleaned up and removed? Is that something zypper dup will eventually do or is that that removal something I need to monitor and manually cleanup? Since I have found several packages besides gcc which fall into this situation, I'm trying to determine whether they all require action on my part or if zypper dup will eventually do it?
On 13.06.2022 00:38, Robert Webb wrote:
Question: Does the operation of the --clean-deps option depend on whether a package was automatically installed or not?
Yes.
The comment in the 'Automatically installed packages' section of the zypper manual implies that it does, but the description under 'remove' does not.
Well, for a start zypper manual lacks definition of "unneeded" in the first place.
On Mon 2022-06-13, Andrei Borzenkov wrote:
The comment in the 'Automatically installed packages' section of the zypper manual implies that it does, but the description under 'remove' does not. Well, for a start zypper manual lacks definition of "unneeded" in the first place.
https://bugzilla.suse.com/show_bug.cgi?id=1200472 "zypper man page doesn't define "unneeded packages"" Gerald
For manual action in the general case, you could >>do: zypper packages --unneeded and then, converting that output to a <package_list>: zypper remove [--dry-run] [-y] [--clean-deps] >> <package_list>
I don't know how to feed the result of the first >> command to the second.
If you are using pwsh (powershell) that is pretty easy to do: $PackageList = zypper packages --unneeded | select-object -skip 4 | ForEach-Object { $_.Split( '|' )[2].Trim() } zypper rm --dry-run --clean-deps $PackageList However, I would be nervous to do them all in a single zypper rm. Instead I'd probably create the $PackageLst and then iterate over it doing zypper rm for each item. bash users could do something similar with cut but I prefer using pwsh for cmdline because it allows me to pass objects through the pipeline instead of raw text.
participants (9)
-
Aaron Puchert -
Andrei Borzenkov -
Carlos E. R. -
Gerald Pfeifer -
Jan Engelhardt -
Joe Salmeri -
Robert Kaiser -
Robert Webb -
Stefan Seyfried