The inefficiencies of pkgdb.db…
Published May 20th, 2007 in GeneralContinuing on with my analysis of the Ruby tools, I find that pkgdb.db is really inefficiently mapping files to packages, and packages to origins.
In the given pkgdb.db I have (which is toy in comparison to my server and other desktops’ pkgdb.db files—only 25 installed packages), I am seeing the following pattern (this is completely random because the BDB Hash DB is dumped in sequential order, and I assume the metadata contents are completely unordered, to some extent):
{?Package Origin
Package Name}
{File attached to package
Package Name}
:origins
{Package Origins}
:pkgnames
{Package Names}
:db_version
{Stamped database version}
:mtime
{The time when the database was made}
Now, that’s all fine and dandy, except for the fact that the pkgdb.db file is extremely bloated. I quickly made a Perl script to analyze the contents of the raw pkgdb.db file. (Link).
The output I obtained was:
analyze_pkgdb.pl < pkgdb-hash.raw
Number of origins found: 48
Package SUMMARY:
autoconf-2.59_2, File count: 63
bash-3.1.17, File count: 86
compat5x-amd64-5.4.0.8_8, File count: 198
db41-4.1.25_4, File count: 910
gamin-0.1.8, File count: 10
gettext-0.16.1_1, File count: 354
glib-2.12.12, File count: 180
gmake-3.81_1, File count: 26
help2man-1.36.4_1, File count: 12
libiconv-1.9.2_2, File count: 19
libtool-1.5.22_4, File count: 25
localedata-5.4, File count: 327
m4-1.4.9, File count: 36
p5-gettext-1.05_1, File count: 5
pciutils-2.2.3, File count: 7
perforce-06.1_6,1, File count: 7
perl-5.8.8, File count: 1970
pkg-config-0.21, File count: 3
pkg_cutleaves-20061113, File count: 2
portupgrade-2.2.6_3,2, File count: 44
ruby-1.8.6,1, File count: 769
ruby18-bdb1-0.2.3, File count: 1
samba-3.0.24,1, File count: 626
vim-lite-7.0.224, File count: 1306
Metadata SUMMARY:
Key: db_version,
Data: 48[7:cFreeBSDic
Key: mtime,
Data: 48u:9Timed8cd21a80@Od8$
Key: origins,
Data: converters/libiconv databases/db41 databases/ruby-bdb1 devel/autoconf259 devel/gamin devel/gettext devel/glib20 devel/gmake devel/libtool15 devel/m4 devel/p5-Locale-gettext devel/perforce devel/pkg-config editors/vim-lite lang/perl5.8 lang/ruby18 misc/compat5x misc/help2man misc/localedata net/samba3 ports-mgmt/pkg_cutleaves ports-mgmt/portupgrade shells/bash sysutils/pciutils
Key: pkgnames,
Data: autoconf-2.59_2 bash-3.1.17 compat5x-amd64-5.4.0.8_8 db41-4.1.25_4 gamin-0.1.8 gettext-0.16.1_1 glib-2.12.12 gmake-3.81_1 help2man-1.36.4_1 libiconv-1.9.2_2 libtool-1.5.22_4 localedata-5.4 m4-1.4.9 p5-gettext-1.05_1 pciutils-2.2.3 perforce-06.1_6,1 perl-5.8.8 pkg-config-0.21 pkg_cutleaves-20061113 portupgrade-2.2.6_3,2 ruby-1.8.6,1 ruby18-bdb1-0.2.3 samba-3.0.24,1 vim-lite-7.0.224
Done
Take a gander at the Perl reference though under Package SUMMARY though. 1970 lines had “perl-5.8.8” in them. That’s 1969 lines more than there should be Add up large ports like OpenOffice, the (Sun) JDK, or all of the X.org ports, and you have one bloated pkgdb.db file.
Of course, it does become an issue if 2 ports own the same file, but that shouldn’t occur and the ports should be setup to conflict with one another in my opinion, instead of causing such a “deadlock”...
Time to ask the port gurus what the next best course of action might be…
Note: A raw copy of the hash version of my pkgdb can be found (here).
No Responses to “The inefficiencies of pkgdb.db…”
Please Wait
Leave a Reply
You must log in to post a comment.