pkgdb – packages database tool

pkgdb – packages database tool

A few short weeks ago, I wrote about portupgrade.
Since then, thanks again to Chris Dillon, I’ve been learning a few more tips about how to use
this wonderful tool. This has proven to be most useful now that I’ve just installed
XFree86-4 and KDE and I need to put my packages database
into a consistent state.

about pkgdb -F

The -F option for pkgdb allows you to “interactively
fix the package registry database”. The following explanation from the man page explains
it quite well:


The pkgdb command also works as an interactive tool for fixing the package
registry database when -F is specified. It helps you resolve stale
dependencies, unlink cyclic dependencies, complete stale or missing origins
and remove duplicates. You have to run this periodically so
portupgrade(1) and other pkg_* tools can work effectively and unfailingly.


An example

Here are some extracts from my package database upgrade. I have snipped out sections
to reduce the amount of fluff you must read.


[root@undef:~] # /usr/local/sbin/pkgdb -F
[Updating the pkgdb in /var/db/pkg ... - 80 packages found (-1 +21) (...)..................... done]
Checking the origin of Mesa-3.4.2_2
Checking the origin of XFree86-4.1.0_10
Checking the origin of aalib-1.2_2
Checking the origin of autoconf-2.52
Checking the origin of autoconf213-2.13.000227
Checking the origin of automake14-1.4.5

[snip]

Checking the origin of xanim-2.80.2
Checking the origin of xchat-1.8.6
Checking the origin of xpm-3.4k
Checking Mesa-3.4.2_2
Checking XFree86-4.1.0_10
Checking aalib-1.2_2
Checking autoconf-2.52

[snip]

Checking gimp-1.2.2_1,1
Stale dependency: gimp-1.2.2_1,1 -> XFree86-libraries-4.1.0_1:
XFree86-4.1.0_10 (score:38%) ? ([y]es/[n]o/[a]ll) [yes] y
Fixed. (-> XFree86-4.1.0_10)


In this case, gimp normally installs XFree86-libraries-4.1.0_1.
In reality, it used XFree86-4.1.0_10 because that was already installed.
You can see that pkgdb thinks it knows the right answer, and suggests it. I answer
y. pkgdb then updates the dependencies.


Stale dependency: gimp-1.2.2_1,1 -> freetype2-2.0.5:
freetype-1.3.1_1 (score:50%) ? ([y]es/[n]o/[a]ll) [yes] n
New dependency? (? to help): XFree86-4.1.0_10
Fixed. (-> XFree86-4.1.0_10)


This is a similar example. I don’t actually have freetype2-2.0.5 installed.
As near as I can tell, this is more art than science. You grep
ports/x11/XFree86-4/pkg-plist for references to freetype.
Or look at /var/db/pkg/XFree86-4.1.0_10/+CONTENTS. Or you can just “know”.


Stale dependency: gtk-1.2.10_3 -> freetype2-2.0.5:
XFree86-4.1.0_10 ? ([y]es/[n]o/[a]ll) [yes] a
Fixed. (-> XFree86-4.1.0_10)


In the above extract, I’ve said that all future references to
freetype2-2.0.5 should automagically replaced by
XFree86-4.1.0_10.


Stale dependency: libungif-4.1.0b1 -> XFree86-libraries-4.1.0_1:
Fixed. (-> XFree86-4.1.0_10)
Stale dependency: libungif-4.1.0b1 -> freetype2-2.0.5:
Fixed. (-> XFree86-4.1.0_10)
Stale dependency: libungif-4.1.0b1 -> imake-4.1.0_1:
Fixed. (-> XFree86-4.1.0_10)


Above, you can see that previously selected defaults have been automagically used.

If you run /usr/local/sbin/pkgdb -F and you don’t get prompted for
anything, then the dependencies are fine.

Yeah, but what’s in it for me?

If you keep your package dependencies in a correct and consistent state,
you will encounter far fewer problems when upgrading your ports. According
to the portupgrade man page, you should always run pkgdb -F
before upgrading a number of ports at once. “An inconsistent package database will surely
cause bad results.”