Re: [ECFT] pkgng 0.1-alpha1: a replacement for pkg_install

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?