On 25/03/2011 11:11, Baptiste Daroussin wrote:
In term of technology we decided to use a sqlite3 database, and to
prevent potential trolling, sqlite3 is used in it's amalgamation form
which means it is incorporated in the code sources (as recommanded by
sqlite developpers like a statically linked library) on build we only
activate the features we need in sqlite.
I'm very glad you went with sqlite3! I've looked at pkgng source a bit
and it looks like you use transactions and foreign keys which is a huge
benefit for the whole effort.
At this time I'd just like to suggest you add the use of WAL journal
(http://www.sqlite.org/pragma.html#pragma_journal_mode) on database
creation so you get the benefits of multiple-readers-single-writer
concurrency model.
The alpha release come with an experimental tool "pkg2ng" to convert
an existing package database to the new pkgng database format. So one
can test pkgng without rebuild all its packages.
Could you change the filename of the database to have the ".sqlite"
extension? It's not important but it indicates what it is used by and
newer software is moving to ".sqlite".
One of the thing we are thinking about pkgng is to perhaps be able to
provide it only as a ports (with simple script in base to
boostrap/install it). That would allow pkgng to live with the ports to
be able to easily integrate new features without having to support
very old version of pkgng.
Maybe I'm misunderstanding but won't that mean that the ports system
without pkgng will continue to maintain their data in the current format?
more informations can be found here:
http://git.etoilebsd.net/pkgng/tree/docs/GOALS,
"""
the database will be a sqlite file compressed with the xz format.
the database will be signed so we can trust the sha256 of the
packages, so if a package has the expected hash, it is considered
trusted.
"""
I'm not sure on what "the database" refers at this point, but is it
really necessary to compress it? I don't mean it's hard to do, just that
maybe it would be simpler without it.
About this signature: hashing like this is very rudimentary. Could you
design this to extensible, expecting real PGP-based signatures in the
future?
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
