Peter Jeremy wrote:
On 2007-May-11 02:10:05 +0200, Ivan Voras <[EMAIL PROTECTED]> 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?
- no strict format - slow - not transaction safe- harder to use then SQL (yes, relatively, but many younger people know SQL better than grep).
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" :-)
They fixed in Win2000 and newer version (mostly by using a sane file system instead of FAT32).
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.
Since fancy new features of sqlite are not needed here, I'd suggest importing the latest 2.x release, which hasn't changed for quite some time.
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.
I don't think the "common usage pattern here" includes warming up the pkg cache :) If you don't think 15 ms per line is bad performance, then we'll just agree do disagree :)
Relying on undocumented features of tools is rarely a good idea. tar
BSDtar is maintained by "our people".
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".
Alternatives to XML are: - binary format (yuck)- another plain text format (hacks such as concatenating existing metadata "files" in the .tar - also yuck).
des@ mentioned putting metadata info at the front of the file - I don't see how this would help. The most common operation with binary packages *over the network* is "pkg_add -r", which will need to read it whole anyway, and it would help greatly for things such as installers from CD media. (Querying a bunch of packages over the network for their properties, one by one, is not a good idea, but it is on a local media).
Anyway, I'm not going to do it, so I'll try and stop bikeshedding :)
signature.asc
Description: OpenPGP digital signature
