The FreeBSD Diary

The FreeBSD Diary (TM) Remember
I remember
[ HOME | TOPICS | INDEX | WEB RESOURCES | BOOKS | CONTRIBUTE | SEARCH | FEEDBACK | FAQ | FORUMS ]

Things look quiet here. But I've been doing a lot of blogging at dan.langille.org because I prefer WordPress now. Not all my posts there are FreeBSD related. I am in the midst of migrating The FreeBSD Diary over to WordPress (and you can read about that here). Once the migration is completed, I'll move the FreeBSD posts into the new FreeBSD Diary website.

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


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