New FreeBSD package system (a.k.a. Daemon Package System (dps))

[Peter Jeremy]

On 2007-May-11 02:10:05 +0200, Ivan Voras <ivoras at fer.hr> wrote:
>- I think it's time to give up on using BDB+directory tree full of text
>files for storing the installed packages database,

Why?

> and I propose all of
>this be replaced by a single SQLite database.

I'll agree with Julian on this one.  When it comes to maintenance, you
can't beat a collection of documented text files.  As a good example
of why non-text databases for system configuration information aren't
a good idea, I suggest you google "windows registry" :-)

> SQLite is public domain
>(can be slurped into base system),

We don't want to unnecessarily increase the size of the base system.
SQLite is also changing at a fairly rapid rate - which is incompatible
with the FreeBSD release cycle.  There have been 6 releases of SQLite
so far this year.  This would lead to a situation where even if we
imported SQLite, we would still need an SQLite port for people who
needed a more up-to-date version.

>as reporting. The current pkg_info's behaviour that takes *noticable*
>*time* to generate 1 line of output per package is horrible in this day
>and age.

After warming up the cache, I get one line every 1.5msec.  Before that,
I get one line every 15-20msec which isn't that bad.

If that is too slow, then build a database as a cache - as long as the
text files remain the master version.  In which case, I'd prefer to
use dbm(3) since it's already in the base system.

>- A quick test confirms that the current bsdtar will happily ignore any
>extra data at the end of a tgz/tbz archive, so package metadata can be
>embedded there, thus conserving existing infrastructure and being fast
>to parse. I suggest encoding this metadata in a sane and easy to parse
>XML structure.

Relying on undocumented features of tools is rarely a good idea.  tar
has other disadvantages (particularly the lack of random access) as a
ports archive format.  ZIP was suggested as an alternative.  I also
question the combination of "sane", "easy to parse" and "XML".

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20070511/3aca8a50/attachment.pgp