Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 May 2007 19:01:18 +1000
From:      Peter Jeremy <peterjeremy@optushome.com.au>
To:        Ivan Voras <ivoras@fer.hr>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: New FreeBSD package system (a.k.a. Daemon Package System (dps))
Message-ID:  <20070511090118.GE826@turion.vk2pj.dyndns.org>
In-Reply-To: <f20c8u$htp$1@sea.gmane.org>
References:  <200705102105.27271.blackdragon@highveldmail.co.za> <f20c8u$htp$1@sea.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--GID0FwUMdk1T2AWN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2007-May-11 02:10:05 +0200, Ivan Voras <ivoras@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".

--=20
Peter Jeremy

--GID0FwUMdk1T2AWN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFGRDDe/opHv/APuIcRAtD5AJ4h2eWIfPzE+k4IxHiH7mI+tfQGnQCfTUFB
Pidw0pwzUiYDVrpn8xRWyJ0=
=n0Ge
-----END PGP SIGNATURE-----

--GID0FwUMdk1T2AWN--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070511090118.GE826>