On Mon, 26 Jul 2004 13:56:01 -0700 (PDT)
"Jeremy C. Reed" <reed@reedmedia.net> wrote:

> We need a database containing the various meta data and information of
> each package. Such as apt-get's "Available" files or Yum's numerous
> specifications. A few months ago, I started building a single file
> containing meta data for thousands of packages, but it was quite slow.

We could generate the INDEX file on a fast machine and commit it to the CVS
on a regular period.  I've been told that this is not so slow nowadays.

> I think we need to add a switch to pkg_info or pkg_admin to generate the
> file or to output the data in the correct format. The way I was doing it
> was to run pkg_info a few times with different switches and then parsing
> out the data to generate new file.
> 
> The single file could be used with package tools to know what needs to be
> updated and how to update (what dependencies, what order, et cetera).

A while ago I started working on a library to access pkgsrc, as well as a
frontend to it: the goal was to create a utility to install/maintain packages,
either from source or binaries (should be completely transparent).  When
working from pkgsrc, it requested the required information (package name,
dependencies, version, etc) on demand, running 'make show-vars' on it and
parsing the results.  No, it's not usable for anything... yet.  I just got to
calculating the dependency tree for a given package, and installing all of
its dependencies in the right order (bypassing pkgsrc's own logic in .mk
files).

What I want to say is that we shouldn't need a single database; if we have it,
fine, and it'll be a lot better (parsing becomes faster and you can do many
fancy things).  But we should be able to workaround its lack.

How does Gentoo's portage cope with this issue?  emerge is very fast scanning
the tree, AFAICT.

Cheers

-- 
Julio M. Merino Vidal <jmmv@menta.net>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/