single eopkg command question

brent

Well it took me years to finally read man eopkg. No surprises but I never use this command:

"autoremove (rmf) <package1> <package2> ...

       Remove a package from the system, along with reverse dependencies and
       any automatically installed packages related to this package that are
       now no longer required. This ensures a full removal for direct
       runtime dependencies instead of just reverse dependencies."

Question 1-
If I started removing packages this way like sudo -rmf nautilus (for example) and just used that it looks like I could take sudo eopkg rmoout my monthly cleaning regime?

in the -rmo text it beautifully cryptically says this "Note that in Solus terminology an orphan is a proveable concept, not an automatic heuristic. Thus, the only
candidates in the algorithm are those packages that
were marked automatic as dependencies of another operation,
and are no longer required by other packages on the system"

So my question is should I uninstall programs -rmfand never worry about using -rmo again? Sounds like it.
Thanks.

Harvey

If it works for you, why not.

But always remember that if you do not know for a fact that what it is suggesting to remove is not needed by something. Leave it alone, its not worth the kb/mb.

I usually install things for testing that I don't want and just use sudo eopkg hs -t # to roll back. I can't say I often use rmf

Harvey

I should probably point out these are not the commands.

sudo -rmf, sudo eopkg -rmf

its sudo eopkg rmf

brent

holy hyacinth batman!
rollback as a single package removal?
you are incredible harvey 🙂 !
I imagine that leaves a system very pristine however

Harvey

You can do eopkg hs and take note of the transaction ID for what you wish to undo. In this example I want to undo what happened in 11301

Operation #11301: install
Date: 2025-09-10 20:09

    * vulkan-headers 1.4.313.0-26-1-x86_64 is installed.
    * vulkan-devel 1.4.313.0-42-1-x86_64 is installed.
    * libpciaccess-devel 0.18.1-14-1-x86_64 is installed.
    * libdrm-devel 2.4.125-52-1-x86_64 is installed.
    * mesalib-devel 25.2.2-279-1-x86_64 is installed.
    * qt6-base-devel 6.9.2-45-1-x86_64 is installed.
    * qt6-languageserver 6.9.2-14-1-x86_64 is installed.
    * qt6-declarative-devel 6.9.2-21-1-x86_64 is installed.

So I use the that id -1
sudo eopkg hs -t 11300

Which removes what happened inbetween and if you look at the history again it will look like this:

Operation #11302: takeback
Date: 2025-09-10 20:09

    * vulkan-headers 1.4.313.0-26-1-x86_64 is removed.
    * vulkan-devel 1.4.313.0-42-1-x86_64 is removed.
    * qt6-languageserver 6.9.2-14-1-x86_64 is removed.
    * qt6-base-devel 6.9.2-45-1-x86_64 is removed.
    * libpciaccess-devel 0.18.1-14-1-x86_64 is removed.
    * qt6-declarative-devel 6.9.2-21-1-x86_64 is removed.
    * mesalib-devel 25.2.2-279-1-x86_64 is removed.
    * libdrm-devel 2.4.125-52-1-x86_64 is removed.

Whatever number you give it, it will try roll back that far. Which due to deprecations is not always possible. When it works properly, you are rolling back the installed packages to the ID you give it.

brent

'takeback' gives verbose confirmation of removal which someone like me likes to know.

so if you had a 'session' with vulkan and qt6 stuff (monkeying around) and wanted it gone, then-t will make you whole again (an expression).

the only danger I can see in this method is not rolling back too far back on the timeline (weeks for instance)?

Original-Syn

I have been learning my way through the Solus tools, and yeah, eopkg had a lot of very cool features that are honestly not well known. It has been fun and enlightening after 30 years of dpkg/apt, rpm/yum/dnf, etc.

brent

Original-Syn I'm getting at that point that man pages are intriguing lately 🙂. not a bad thing at all. never stop learning