The FreeBSD Diary

The FreeBSD Diary (TM)

Providing practical examples since 1998

If you buy from Amazon USA, please support us by using this link.
[ HOME | TOPICS | INDEX | WEB RESOURCES | BOOKS | CONTRIBUTE | SEARCH | FEEDBACK | FAQ | FORUMS ]
pkgdb - packages database tool 28 December 2001
Need more help on this topic? Click here
This article has 3 comments
Show me similar articles

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."


Need more help on this topic? Click here
This article has 3 comments
Show me similar articles