pkg autoremove removes wrong packages

Voltaire

Voltaire

I've noticed something in pkg autoremove's behavior that could potentially be a bug or unwanted behavior.
Yesterday I did pkg autoremove. These were the packages it then removed:
docbook, docbook-sgml, docbook-xml, docbook-xsl, iso8879, kf5-kdoctools, sdocbook-xml, xmlcatmgr, xmlcharent
Click to expand...

I've only installed packages via pkg, and never installed custom builds or anything like that.
If I do pkg upgrade after this, the packages that have just been removed are reinstalled.

I did some research and found these things:
forums.freebsd.org

the usual not logical behaviour of pkg autoremove

Like in the subject. It never been coherent to me. On a brand new 64 bit box I just built using port and working perfectly fine I do have this situazione: $ sudo pkg check -d Password: Checking all packages: 100% $ Then if I run autoremove to clean some bit up, it propose to delete even...
forums.freebsd.org forums.freebsd.org

137052 – Dependency problems between textproc/docbook-xsl and textproc/docbook

bugs.freebsd.org bugs.freebsd.org
forums.freebsd.org

pkg autoremove: totally unreliable

Like in the subject. The experience with this pkg autoremove command is totally tragic in this perfectly working FreeBSD 11.0-RELEASE system. % sudo pkg autoremove Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 63 packages: Installed packages...
forums.freebsd.org forums.freebsd.org

Docbook seems to have been a problem in the past when using autoremove. It shouldn't be removed.
What I'm wondering is if this is a bug in pkg, or can I somehow avoid this behavior of pkg?
 
Voltaire said:
What I'm wondering is if this is a bug in pkg, or can I somehow avoid this behavior of pkg?
Click to expand...
You can set a package as "non-automatic", normally if packages are installed as a dependency of something they are marked as "automatic". pkg-autoremove(8) removes packages that are automatically installed and don't appear to be a dependency any more. For example, if you install package A and it has package B as a dependency, A is marked as "non-automatic" and B as "automatic". If you later on remove A then a pkg-autoremove(8) will remove B. To prevent this (if you really want to keep package B); pkg set -A0 packageB.

Code: 
     -A 01, --automatic 01
                Set automatic flag for the package: 0 is not automatic, 1 is
                automatic.  This affects the operation of pkg-autoremove(8).
See pkg-set(8)
 
You can set a package as "non-automatic", normally if packages are installed as a dependency of something they are marked as "automatic". pkg-autoremove(8) removes packages that are automatically installed and don't appear to be a dependency any more. For example, if you install package A and it has package B as a dependency, A is marked as "non-automatic" and B as "automatic". If you later on remove A then a pkg-autoremove(8) will remove B. To prevent this (if you really want to keep package B); pkg set -A0 packageB.
Click to expand...
Should I mark the problematic packages as 'not automatic' or should I leave it as it is? Can a future update of pkg fix the current problem or will the packages always be removed in the future when I run pkg autoremove?
 
It's possible a package has an incorrect dependency list. That can happen due to errors in the port for example. Then a dependency would be 'lost' and pkg-autoremove(8) would think it's OK to remove those, now unused, dependencies. If that dependency error gets fixed then the chain would be good again.

But most of the packages you listed seem like build dependencies to me. You don't need to have them around, only when building a port that requires them. It's possible they got erroneously dragged in at some point as run or library dependencies.

I would let pkg-autoremove(8) remove them. Then see if anything breaks.
 
You must log in or register to reply here.
Back
Top