“Thank you” to those of you who kindly took some time to post some information here. In partly following poster tannington’s generalization I removed all of the lib…, python-…, and python2-… software packages listed in the output following my entry of the command
zypper pa –orphaned
as a “root” user in my Leap-15.4 installation. The output of that command was in a tabular form with the so-qualified, software-package names in a column.
Item 1, a question: How could I instead have used “grep” within the above command to 1) provide just the package names in a row with consecutive package names in a so-produced list in each case separated by one space? The utility of such a result could be to enable the copying and “pasting” of that row of software package names into one “zypper rm …” command. And
Item 2, a question: how could I have used “grep” within a
zypper pa –orphaned
command to list packages with names beginning with “lib” and “python”?
Next I would like to know whether the texlive-… software packages in the output of
zypper pa –orphaned
would be functional in my Leap-15.4 installation or not. After all, it would not make sense for me to keep any old Teχ Live packages in my Leap-15.4 installation if they would not be functional in that installation.
I found indications from https://www.educba.com/linux-distributions/ and https://www.texdev.net/2011/10/29/tex-live-in-linux-distributions/ on the Internet that a version of a texlive-… software package provided via a distributor of a Linux operating system might possibly be kernel dependent. Then in Yet another Software Tool (YaST) Software for the package named “texlive” I saw that its version number included both “2021” for probably the year of Teχ Live and “150400”, which is part of my currently running Linux kernel version of “5.14.21-150400.24.18-default”! And that same number of “150400” appears in numerous other texlive-… software package version numbers which also include the number “2021” in them. So I suppose that many texlive-… software packages in my Leap-15.4 installation with both “2021” and “150400” in their version numbers may be dependent on at least the current series of Linux kernels which include “150400” in their version numbers. Similarly among a large number of the “orphaned,” texlive-… software packages in my Leap-15.4 installation I found that their version numbers include both “2017” and “5.18” in their version numbers. And among them, for example texlive-knuth and texlive-tabulars-e, were installed in my Leap-15.4 installation on July 13, 2021 when I was using Leap 15.3. And in my former Leap-15.3 installation I was usually, if not always using Linux kernels with “5.3.18” in their version numbers. So I suppose that all members of that set of “orphaned,” texlive-… software packages were kernel dependent. For the remaining 10, “orphaned” texlive-… sofware packages which all have “2017” in their version numbers, but not “5.18” in their version numbers, all ten of them were installed on July 13, 2021 in my then, Leap-15.3 installation.
So here is what I suppose or speculate that openSUSE developers might have been doing concerning texlive- software packages: a) obtaining them in primitive forms, perhaps as source-code files from Teχ Live from the Teχ Users Group (TUG) or perhaps the Comprehensive Teχ Archive Network (CTAN), b) perhaps modifying them in ways to make them usable in the latest version of openSUSE with its Linux kernels, possibly backporting some kernel-appropriate computer code; and c) providing such a modified software package in an openSUSE, online repository. In anticipation of the types of content to be used in Linux kernels in Leap 15.4 perhaps those so-produced, texlive-… software packages would not need to be compiled at the time of their installations, but instead might be released from an online openSUSE repository having already been compiled.
Item 3, a question: Do you agree with my thinking and speculations in my previous two paragraphs? If not, please correct my writing here.
Some relevance of part of my previous discussion to deciding whether or not to remove “orphaned,” texlive-… software packages is that it is conceivable that such texlive-… packages produced for use in one set of Linux kernels used in my Leap-15.3 installation might not work in the Linux kernels in and to be used in my Leap-15.4 installation; and if those “orphaned” texlive-… software packages would turn out to not work in my Leap-15.4 installation, I should remove them from my Leap-15.4 installation.
Regarding Linux kernels I recently moved all of my remaining versions of initrd [initial RAM (Random Access Memory) disk] from the directory /boot into the “trash” directory, except for initrd files corresponding to the latest two versions of the Linux kernel in the latest openSUSE operating system. Correspondingly in /etc/zypp/zypp.conf I have a statement reading
multiversion.kernels = latest, latest-1,running
. And, according to the procedure posted on https://forums.opensuse.org/showthread.php/572815-dracut-generates-initrd-files-for-kernels-that-are-no-longer-on-my-system on the Internet, I moved to the “trash” directory all of the subfolders or subfolders of subfolders which contained Linux kernel modules within /lib/modules, except for kernel modules for the latest two Linux kernels. And at some future time, in the absence of related software problems, I hope to empty that “trash” directory. And I executed the command
zypper purge-kernels
as a “root” user.
And after a future, Linux kernel update is installed I should check in /lib/modules to see whether a subfolder of /lib/modules containing kernel modules for two kernel versions prior to the updated kernel version will remain there or not; and if that subfolder of /lib/modules will then be there, I should delete it. Based on my experience and some reading on https://forums.opensuse.org/showthread.php/572815-dracut-generates-initrd-files-for-kernels-that-are-no-longer-on-my-system, for Linux kernels which are not going to be used in the future, deleting unused initrd files and unused kernel-module subfolders of /lib/modules might shorten processes in which new initrd files will be produced.
There is a possibility that the function of an old texlive-… software package from Teχ Live 2017 could have been replaced by a texlive-… software package with a different name in a year-2018, 2019, 2020, or 2021 version of Teχ Live; and if such a replacement of function was indeed made, the old, “orphaned,” texlive-… software package should be removed my Leap-15.4 installation. An imaginable way that such a possibility might be checked might be to scan the so-called changelogs for the year-2018, 2019, 2020, and 2021 versions of Teχ Live, if they were all thoroughly produced and can be found somewhere online.
To somehow learn how to work with each of 35, relatively old,“orphaned,” texlive-… software packages and afterward to test each of them, one at a time, in a LaTeχ, .tex file using one or both of the computer programs pdflatex or bibtex might take a large amount of time!
Item 4, a question: So instead is there a way I may determine en masse, or in a group, whether each of the installed “orphaned” texlive-… packages will be functional or not in my Leap-15.4 installation, perhaps in a short .tex file which would include a \usepackage{…} statement and between those braces have all of the “orphaned” texlive-… package names minus “texlive-” in each case and separated by commas?
…