Zypper now supports orphans clean-up

Relatively requently asked feature.

zypper-1.14.70 will support a new option: ‘dup --remove-orphaned’ to remove all unneeded orphans. - openSUSE Factory - openSUSE Mailing Lists

1 Like

You have to be careful using this. Just because a package is an orphan does not mean that it is uneeded (learned that the hard way). If you read through the thread referenced there are hints at how to avoid this.

3 Likes

To be clear, my comment isn’t directed at the quoted Reply (or respondent).

It’s clear, TW has had a tendency to add bloatware (unneeded) packages. Not sure why - is it some sort of “let’s install these just to avoid problems”?

An example - the typical recommendation to update TW is to execute
“zypper [-vv] dup”
( I show the verbose mode as an option because I was recently criticized for recommending it in a thread ).

I showed how a bunch of extra packages were going to also be installed (bloatware). I got a reply that “–no-recommends” would not bring in all those packages. So, why isn’t “–no-recommends” a default to avoid bloatware (?)

And now, we’ve got a new option to do the opposite - to remove orphaned packages … but with the possible side-effect that it might remove needed packages. So now we have to sift thru a mail-list thread to figure out how to mitigate the side-effects of the new “clean up” feature (?).

Let’s hope a proper How-to will be provided for the –remove-orphaned option.

1 Like

@aggie the openSUSE defaults are very generic in nature, it’s up the the system administrator (you?) to select what is best for their setup/environment… FWIW I always recommend verbose output (I use -vvv :wink:).

Package installation is by nature very subjective, one users recommends (or suggests) is another users requires… For example *-lang packages are recommends these days, set no-recommends to the defaults and then the folks that require them get confused/upset.

Test and use the options that work for you, then you can decide what’s best.

5 Likes

Back to basics, folks.

bruno@LT-B:~> zypper packages --help
packages (pa) [OPTIONS] [REPOSITORY] ...

List all packages available in specified repositories.

  Command options:

    --orphaned              Show packages which are orphaned (without repository). Default: false
    --suggested             Show packages which are suggested. Default: false
    --recommended           Show packages which are recommended. Default: false
    --unneeded              Show packages which are unneeded. Default: false
<snip>

so I read “option to remove unneeded orphans” as removing packages that are not currently in an enabled repository and are unneeded, so that no other installed package asks for them as a dependency.
Please check with:

bruno@LT-B:~> zypper --no-refresh packages --orphaned
Loading repository data...
Reading installed packages...
S  | Repository | Name              | Version  | Arch
---+------------+-------------------+----------+-------
i+ | @System    | <a pkg I installed via rpm> | 4.3.89-1 | x86_64
bruno@LT-B:~> 
bruno@LT-B:~> zypper --no-refresh packages --unneeded
Loading repository data...
Reading installed packages...
S | Repository            | Name                         | Version                         | Arch
--+-----------------------+------------------------------+---------------------------------+-------
i | Main Repository (OSS) | adjtimex                     | 1.29-8.17                       | x86_64
i | Main Repository (OSS) | AppStream                    | 1.0.2-2.2                       | x86_64
<snip>
a bunch of packages, most of the DE actually, with an 'i' in the first column
<snip>
i | Main Repository (OSS) | zypper-lifecycle-plugin      | 0.6.1601367426.843fe7a-3.8      | noarch
bruno@LT-B:~>

So, as suggested in the original linked post, just include in a plain rpm repo those “orphans” you like to keep.
I don’t see much reason to be worried.

2 Likes

Might be to minimize frequency of n00bs writing in mailing lists, forums and IRC the equivalent of “Other distros provide…Why doesn’t openSUSE?”

‘solver.onlyRequires = true’ in zypp.conf has an effect equivalent to --no-recommends.

3 Likes

Recommended packages and orphaned packages are two complete different things and NOT each others opposite.

“Orphaned packages” means that not they are being offered by any active repo at that moment in time. Could be “recommended” ones (where later the repo is removed). Could be ones that do not fall in the category “recommended”.

“Bloatware” is of course in the eyes of the beholder. There is no technical definition in the context of zypper .

“Unneeded” is another one that, as far as I know, has no technical definition in he context of zypper . The question I ask is always: unneeded by whom for what?

Make new installation with solver.onlyRequires = true and tell us your experience.

Please see:

zypper packages --unneeded

FWIW those are packages that were “automatically selected by the solver” (once recommended? Part of a pattern?) but that are not required by any other installed package.
I read that as “you can remove them without breaking anything else” than the functionality provided by the “unneeded” package itself.

Package is unneeded when no other installed package requires or recommends it. This has been discussed much more than once on these forums.

This is on my openSUSE Leap 15.5 system: openSUSE Paste

I really wonder what the practical use of this list is.

Yea, I’ve had that setting enabled for a long time, on the laptop :+1:

1 Like

I did not say “enable them on your system”. I said “install your system fresh without any recommended package”.

1 Like

So, I just installed TW in a VBox using today’s install ISO. (I only installed from the ISO and did not enable online-repos for the install). After the install, I configured solver.onlyRequires = true in zypp.conf.

I then ran

# zypper in rstudio
The following 49 NEW packages are going to be installed:
[ ... ]
49 new packages to install.
[ ... ]

I compared it to my other system, which resulted in:

The following 7 recommended packages were automatically selected:
  gcc gcc-c++ git git-email libclang13 mathjax pandoc-cli
The following 2 packages are suggested, but will not be installed:
  rstudio-desktop rstudio-server

The following 272 NEW packages are going to be installed:
[ ...  a bunch of packages listed here ...]
272 new packages to install.

So yea, better to configure for that just after installing TW … Thanks !!

I see a contradiction here (and the emphasize is mine).

I guess that is not what @arvidjaar was proposing.

While in the installer you can already set the option to install without recommended packages (all my openSUSE Tumbleweed systems are installed this way). This will give you a system with ca. 30% less packages (compared to a “normal” installation).

But beware that system might need quite some “maintenance” after installation (and probably not only directly after installation but later on as well). If you don’t feel comfortable with the command line that can become a quite challanging exercise.

1 Like

And @arvidjaar proposal was triggered by

So we are still wating for @aggie 's experience when testing what would happen if --no-recommends would be a default at installation.

As I have installed all my openSUSE Tumbleweed systems that way here some of my “most embarrassing encounters”:

  • Although plasma was installed there was no displaymanager installed to start it.
  • Although a language was selected in the installer many language packages were missing
  • Although plasma was installed there were no password-entry-dialogs installed (that was a tricky one to sort out).
  • Many parts of Yast were not installed.
  • No editor was installed (not even vi)
  • No man-pages were installed

I personally would argue that some of the results (caused by selecting –no-recommends from the very beginning) do not really make sense but I definitely don’t want to start this discussion again.

On the other hand the final system has ~30% less packages and therefore takes less bandwidth and time to update.

Personally, I’ll take a little bloat if it means tracking down fewer common dependencies for third party stuff. Nice feature to have though.

There will appear a zypper remove --remove-unneeded: