Discussion about handling orphaned packages

[anon71037787]

networkmanager-fortisslvpn shows not up as an orphaned package.
And could we automate the removal of orphans, to avoid issues like this?
Like as part of the update process?

[Ankur]

@anon71037787

could we automate the removal of orphans

It might lead to an unrepairable situation in future!
Automating everything is not a good idea, maybe due to some fault if an important system package got listed there then it might lead to some problem .
cleanup is an easy to use alias for these things .

[NaN]

@anon71037787

networkmanager-fortisslvpn shows not up as an orphaned package.

It is orphaned in AUR upstream not on local system.

paru -Ss networkmanager-fortisslvpn
aur/networkmanager-fortisslvpn 1.4.0-3 [+0 ~0.00] [Orphaned]
NetworkManager VPN plugin for Fortinet SSLVPN
aur/networkmanager-fortisslvpn-peerdns 1.4rc1-1 [+1 ~0.00] [Out-of-date: 2022-07-01]
Fortinet SSLVPN support for NetworkManager
aur/networkmanager-fortisslvpn-git 1.4.1.dev.r33.g0f1b6f9-1 [+16 ~0.00] [Orphaned]
NetworkManager VPN plugin for fortisslvpn - git checkout

@anon71037787

And could we automate the removal of orphans, to avoid issues like this?

Would have to ask the devs about that

[anon71037787]

Seems like a bad idea, to depend Garuda packages on orphaned software.
We could catch this on the server, before it even gets to the user.
No?

[anon71037787]

Yeah, you are right on the local side. On the packaging side, there is no reason why we shouldn’t be notified, at least, that one of our dependencies got lost.

That’s at least, how I understand it now.

[BluishHumility]

@anon71037787

And could we automate the removal of orphans, to avoid issues like this?

You could easily make a Pacman hook to remove orphans, but it is not a good idea because removing the package is only one way to deal with an orphaned package. The other option is to mark the package as explicitly installed and keep it.

All orphans should be carefully reviewed before you remove them to make sure a needed or desired package is not being removed. Keep in mind, an orphan is just a package that was installed as a dependency, but is no longer required by any package. It doesn’t necessarily mean the package is no longer useful. It is up to the user to determine whether the package should be removed, or instead marked as explicitly installed.

Further to this, it is good to be aware that the command suggested in the ArchWiki for removing orphans (here) is very aggressive. A major drawback of recursively removing orphans with this method is it can include packages that are optional dependencies of other packages.

A much safer option is to run sudo pacman -R $(pacman -Qdtq) a few times in a row (until pacman -Qdtg no longer returns anything) as mentioned in this discussion from another forum: How to delete orphaned packages - Pacman vs. Pamac - Pacman - EndeavourOS

From that same discussion, another user has created a function designed to remove orphans with this safer removal method in mind:

orph() {
	while [[ $(pacman -Qdtq) ]]
	 do	sudo pacman -R $(pacman -Qdtq)
	done
}

To circle back to the point, the TL;DR would be: no, removing orphans should not be automated because removal is not always the correct choice for dealing with an orphaned package.

[anon71037787]

@BluishHumility

Further to this, it is good to be aware that the command suggested in the ArchWiki for removing orphans (here ) is very aggressive. A major drawback of recursively removing orphans with this method is it can include packages that are optional dependencies of other packages.

Garuda seems to implement it almost identically

alias cleanup='sudo pacman -Rns (pacman -Qtdq)'

Thanks a lot for that detailed explanation.

And again, I mean, that we create a way to detect orphaned packages on the main package server.
So, as Kiss-my-axe described, could have been this issue prevented, if we knew, that networkmanager-fortisslvpn has moved.

We dependent on a package, and had no way to recognize that it was no longer available.
I am sure, we can automate a mechanism, that makes us aware about that next time.

[anon71037787]

@BluishHumility

orph() {
	while [[ $(pacman -Qdtq) ]]
	 do	sudo pacman -R $(pacman -Qdtq)
	done
}

So you mean something like this in fish:

function cleanup
   while pacman -Qdtq
      sudo pacman -R --noconfirm (pacman -Qdtq)
   end
end

Wouldn’t that warrant a PR, that replaces the current cleanup?

[BluishHumility]

@anon71037787

Garuda seems to implement it almost identically

alias cleanup='sudo pacman -Rns (pacman -Qtdq)'

That’s right, this command can be very aggressive. In certain situations it can snowball into a huge package list that includes a lot of important packages. It shouldn’t be run without inspecting the targeted packages very closely. You can easily break your system with this command.

@anon71037787

And again, I mean, that we create a way to detect orphaned packages on the main package server.

Okay I think I see the confusion here. You keep saying “orphans” but now I am understanding that it is not the term you mean to say, or it does not mean what you think it means. I was responding to this sentence:

@anon71037787

And could we automate the removal of orphans, to avoid issues like this?

An orphan is a package which is installed as a dependency, but is no longer required by any package. That is different from the original issue, where a dependency no longer exists as an available package at all.

Orphans do not exist in the package repositories. That type of dependency relationship is not established until the packages are actually installed.

I think what you are suggesting is there should be automation for a package to detect when one of its dependencies no longer exists. To be honest I really don’t know how practical or useful that would be, but two considerations come to mind off the top of my head:

1. It is not something that happens very often.
2. When a package has a dependency that no longer exists, probably the package maintainer will need to take a look at the package anyway and decide if additional intervention is needed.

@anon71037787

So you mean something like this in fish:

function cleanup
	while test "$pacman -Qdtq" = true
	sudo pacman -R $(pacman -Qdtq)
   end
end

Wouldn’t that warrant a PR, that replaces the current cleanup?

I believe the team is discussing it to see if a change should be made to adopt a more conservative approach to removing orphans.

[anon71037787]

@BluishHumility

You keep saying “orphans” but now I am understanding that it is not the term you mean to say, or it does not mean what you think it means.

Yeah, I just ran with the usage from Kiss my axe.

@NaN

It is orphaned in AUR upstream not on local system.

[NaN]

Well in my defence that’s the tag AUR and arch repo maintainers use.

[anon71037787]

I reworked and tested the fish implementation.
The initial post was just a very rough estimation, this one does happen to work:

function cleanup
   while pacman -Qdtq
      sudo pacman -R --noconfirm (pacman -Qdtq)
   end
end

This has a merge request now.

[NaN]

@anon71037787

sudo pacman -R --noconfirm (pacman -Qdtq)

I am not sure you should have a --noconfirm option there. The way I see it this script ended up doing exactly what BluishHumility said ppl should avoid. Removing packages that are essential. If this script is run wouldn’t this just end up deleting all the packages that are marked as orphan in your system regardless of weather you want to or not, even worse it doesn’t even ask this time…

[BluishHumility]

That’s right, orphans should be carefully reviewed before being removed. Certain things can cause useful or needed packages to become orphans, in which case they should be marked as explicly installed (sudo pacman -D --asexplicit [package name])–not uninstalled.

Check out these threads, where removing all the orphans would have removed a lot of needed packages:

Sudo pacman -Rns (pacman -Qtdq) deletes almost everything

Hello, I'm having trouble with the cleanup command A.K.A sudo pacman -Rns (pacman -Qtdq) It is removing stuff it shouldn't. Its as if pacman forgot the dependencies or forgot what was explicitly installed cleanup checking dependencies... :: apr-util optionally requires mariadb-libs: enable mysql/mariadb support :: apr-util optionally requires postgresql-libs: enable postgres support :: autorandr optionally requires zsh-completions: auto-completion for autorandr in ZSH :: bashtop optionally r…

Suddenly many incorrectly orphaned packages

I was doing a routine update, and suddenly see many packages marked 'orphaned'. I've seen something similar happen when my local repo distrusts packages in routine due to maintainer change. Generally this is easy enough to handle en masse with aurto add $(pacman -Qqm) however this time is different... The packages marked orphaned here are NOT ones that I've added to a local repo, they're from Chaotic-AUR! Upon reinstallation they are still marked orphans; why would this happen? [tech@mango ~]$…

Most orphans come from uninstalling a package and leaving dependencies behind, but as you can see it is not always so cut and dry. In my opinion orphaned packages should be examined with the same careful consideration a .pacnew file would get. Ideally the user would determine what the package is and why it has become an orphan, then decide if it is something they need to keep or not.

The main point I was trying to make is recursively removing packages (such as with pacman -Qtdq | pacman -Rns - ) is much more aggressive than people probably realize because it can include optional dependencies for other packages. If you’re not careful you can throw the baby out with the bathwater.

[Mantion]

I think realistically most people needing advice on how to handle orphans simply don’t have the capacity to

@BluishHumility

carefully reviewed before being removed

As long as snapper is working and the user understands how to use it I see little risk in suggesting --noconfirm. Seems like forcing the un-experienced to blindly click Y added needless complexity to a simple task .

[BluishHumility]

@Mantion

As long as snapper is working and the user understands how to use it I see little risk in suggesting --noconfirm.

Really, you don’t see any risk in removing packages from your system without seeing what they are?

@Mantion

Seems like forcing the un-experienced to blindly click Y added needless complexity to a simple task .

It is adding the --noconfirm option which makes this a blind task, for any experience level.

If someone is so inept at system maintenance that they cannot manage to read through a list of packages and decide if they want to uninstall them or not, then it is unlikely they will be running scripts to clear orphaned packages off their system anyway.

[anon71037787]

@BluishHumility

The main point I was trying to make is recursively removing packages (such as with pacman -Qtdq | pacman -Rns - ) is much more aggressive than people probably realize because it can include optional dependencies for other packages. If you’re not careful you can throw the baby out with the bathwater.

Really, this is a packaging issue.

If packages are added to the orphan status, while they could break your system if removed, is this something that we could consider a packaging bug.

It is called optional dependencies for a reason.
And I personally think, we should avoid optdepends at all.

@BluishHumility

If someone is so inept at system maintenance that they cannot manage to read through a list of packages and decide if they want to uninstall them or not, then it is unlikely they will be running scripts to clear orphaned packages off their system anyway.

I personally disagree with this.

As I wrote this code of block yesterday, I used Blender as an experimental package, to test, if the command does, what I want it to do.

And honestly, I don’t know what most of its dependencies do.

I use the command line all the time, I am programming the whole day, and I definitely don’t know what 2000+ packages on my system do.

How should I?

Do you seriously know thousands of packages, and what they do?

I mean, this is why we have package management in the first place.
To not need to know what all these small pieces are doing, and how they are related.

Shifting this effort to the user, is not only unrealistic, it defeats the purpose of packaging.

As someone said, Snapper is there.

Garuda has by far the best implementation of a rollback system, and it is one of the huge reasons why I switched over from my previous distro after 7 years of using that. Alternatively, just leave the orphans to rot.

What is probably far more interesting to people, is to clean old pkg.tar.zst:
I just did this with the Octopi Cache Cleaner, and I had 6.44 GB collected in just one month.
I guess most users don’t even know about this.

And I think we could talk about changing that default setting to something more sane.

[BluishHumility]

Uninstalling orphans is not the only possible course of action. I am not sure why this point is not coming across.

When the system announces the presence of orphans, it is only pointing out that some of the users packages have a declared dependency relationship that doesn’t exist. The main reason this happens is because a package was uninstalled without removing the dependencies, so uninstalling the packages is harmless. But that is not the only reason it happens, and uninstalling the packages is not always the best choice.

I feel like I explained this multiple times already and I even gave examples from the forum above. I’m not sure what else to say.

The notion that we need to make the option of blindly removing packages safe somehow is ridiculous. Like I said, uninstalling the packages is only one possible choice; the user must decide for themselves.

@anon71037787

Alternatively, just leave the orphans to rot.

This is correct. If you don’t understand what the command you are running which removes a lot of packages is doing, then don’t do it.

@anon71037787

What is probably far more interesting to people, is to clean old pkg.tar.zst:
I just did this with the Octopi Cache Cleaner, and I had 6.44 GB collected in just one month.

The defaults for paccache are pretty conservative (as in, a lot is saved). You can automate cleaning the cache more aggressively if you want with paccache.timer:

https://wiki.archlinux.org/title/pacman#Cleaning_the_package_cache

[Javabean]

as a test for this conversation i went ahead and installed garuda-dr460nized-gaming-linux-zen-230501.iso onto a clean vm(using the opensource drivers option to boot the installer). after cancelling the setup wizard and setting my pacoloco cache. i ran update(ps the fortisslvpn conflict is still inplace) i tryed running cleanup. it wanted to remove glibmm-2.68 kjs libindicator-gtk3 libsidplay lua52 lua53 nlohmann-json openfortivpn python-future qt6-5compat re2 sysfsutils tinycompress . i don’t know how important those are for STOCK dr460nized gaming, but i agree about being careful with such commands.

[BluishHumility]

@Javabean

i tryed running cleanup. it wanted to remove glibmm-2.68 kjs libindicator-gtk3 libsidplay lua52 lua53 nlohmann-json openfortivpn python-future qt6-5compat re2 sysfsutils tinycompress

I think this illustrates @anon71037787’s point, that oftentimes it is difficult or impossible to determine the significance of the orphans being removed. To which I say: fair enough.

No, I don’t think the user should have to study every dependency they have installed to determine what purpose it serves. If they trust the packages they have installed then that should be enough.

Still, I think it is important to review the orphans before uninstalling them. At the very least, if a package the user recognizes has been marked as an orphan they can have the opportunity to react, and abort the transaction if needed.

(By the way @anon71037787 I noticed the merge request has already been amended to remove the --noconfirm flag, so thank you for taking another look ).

I think the merge request is good; switching to this safer method for removing orphaned packages will better serve users who want to clean up unneeded packages with less risk of “over-pruning”.