Hi,
On Fri, May 09, 2008 at 01:52:46PM +0200, Anders Nore wrote:
> I'm working on adding .db support to the pkg_tools
I hope that you know that you're stepping into a hotly debated part of
the project... Good luck. My advice to you is to ignore any calls for
a 'complete rewrite' and to focus on releasing small patches from your
project rather than one big patch at the end. Back each patch up with
performance numbers (I suggest pkg_add gnome2-x (from a local package
source), pkg_version and pkg_delete -r glib-2.x).
> The way I'm thinking of storing information to the .db is to name the
> keys as the directory names in /var/db/pkg. And save the +* files in
> the directories to the value element in the db, separated with a
> special character or similar.
I think this is a really bad idea. The problem with the tools is not
with the files. It is that the files need to be parsed on each run,
often recursively, and your solution would not help at all.
The database(s) should just be a cache of the information stored in the
files. This is what the existing databases used by portupgrade and
NetBSD's tools do. They store the files and which ports installed them,
so that it is easy to do conflict resolution, and some pkg_info
operations.
In addition, what you need is a cache which stores {pkg_name,pkg_origin}
pairs, where both are unique keys with a 1:1 relationship, and then a
{pkg_name,pkg_dep_name} directed graph, which stores the dependency
network between ports (aslo replacing +REQUIRED_BY). Both can be
reconstructed if needed from the +CONTENTS files. You could do both in
BDB, but you'll be better off loading both into memory completely (as
needed), using C to do the queries, and just maintaining the database
when things change (on pkg_add or pkg_delete).
SQLite would make this job easier in some ways, but hurt in others. You
could use queries, which would make what was going on much more obvious,
but then it would be slower. You also have to fight the anti-SQLite
lobby.
Ignore people who talk about disk space on embedded systems. They're
just trolling. ;-) If they don't have the disk space for /var/db/pkg,
then they don't have the space for the ports themselves. Besides,
removing the redundant copy of +MTREE_DIRS for each package would save
more space (and is as easy as checking the CVS revision of the new file
in each package and updating a single master copy (even
/etc/mtree/BSD.local.dist), if it is newer).
With regards to locking, which someone raised, the package tools are a
long way away from parallel modifications to /var/db/pkg. People are
talking about parallel ports builds, but those have small windows where
the package database is being updated, and those updates need to be
sync'ed via a lock.
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
