regenerating /var/db/pkg

b. f. bf1783 at googlemail.com
Thu Apr 22 18:48:46 UTC 2010


Doug Barton wrote:
>On 4/20/2010 7:11 PM, Aryeh M. Friedman wrote:
>> I acciddentally rm'ed my /var/db/pkg and want to know is it possible to
>> rgenerate it (I have portmaster and portupgrade installed)
>
>Portmaster certainly can't do this, it uses the information from
>/var/db/pkg. I'm not sure if portupgrade can do it or not.
>
>Your most likely course of success is to generate a list of ports that
>you know you're using ("root" and "leaf" ports in portmaster
>terminology), back up any config or other key files from /usr/local,
>then delete everything and reinstall.

With regard to portupgrade, if your pkgdb file is intact, you should
be able to reconstruct /var/db/pkg, although it may not be very
convenient to do so. Unfortunately, by default the pkgdb file is
/var/db/pkg/pkgdb.db, so it is often wiped out along with the rest of
/var/db/pkg.  However, if it is intact, make sure you first back it up
before attempting to use it's contents, because most of the pkgtools
attempt to edit it to correspond with the current state of /var/db/pkg
(performing the equivalent of pkgdb -u/-aF) when invoked.  You may be
able to disable this editing via the "-O" flag, but I haven't checked
this lately.

If you have a list of installed packages, and a corresponding ports
tree, you could reconstruct most but probably not all of /var/db/pkg
by running "make generate-plist fake-pkg" in the ports tree origin of
each package (if you built the packages with non-default options, you
should have an intact /var/db/ports for this to fully work).   The
directories for packages with dynamic plists might not be fully
restored without rebuilding the ports, but this may be enough for a
first pass.  You could then prune or account for files in
PREFIX/LOCALBASE that aren't listed as belonging to a registered
package, via something like:

find /usr/local -type f -print0 | xargs -0 pkg_which -v | fgrep '?'

or with something similar using "pkg_info -W..." instead of "pkg_which -v".

Alternatively, if you have backups of all the installed packages, or
can obtain them from a server, you could use their packing lists to
restore /var/db/pkg.

But as Doug suggests, a full cleanup of PREFIX/LOCALBASE and
reinstallation of all leaf packages may be easier than a
reconstruction of /var/db/pkg.

b.


More information about the freebsd-hackers mailing list