Date: Fri, 11 May 2007 11:19:13 +0200 From: Ivan Voras <ivoras@fer.hr> To: freebsd-hackers@freebsd.org Subject: Re: New FreeBSD package system (a.k.a. Daemon Package System (dps)) Message-ID: <f21cen$iev$1@sea.gmane.org> In-Reply-To: <20070511090118.GE826@turion.vk2pj.dyndns.org> References: <200705102105.27271.blackdragon@highveldmail.co.za> <f20c8u$htp$1@sea.gmane.org> <20070511090118.GE826@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA1C266F0560A81607C164753 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Peter Jeremy wrote: > 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 tex= t >> files for storing the installed packages database, >=20 > Why? - no strict format - slow - not transaction safe - harder to use then SQL (yes, relatively, but many younger people know=20 SQL better than grep). >> and I propose all of >> this be replaced by a single SQLite database. >=20 > 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=20 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=20 importing the latest 2.x release, which hasn't changed for quite some tim= e. >> as reporting. The current pkg_info's behaviour that takes *noticable* >> *time* to generate 1 line of output per package is horrible in this da= y >> and age. >=20 > 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=20 pkg cache :) If you don't think 15 ms per line is bad performance, then=20 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=20 metadata "files" in the .tar - also yuck). des@ mentioned putting metadata info at the front of the file - I don't=20 see how this would help. The most common operation with binary packages=20 *over the network* is "pkg_add -r", which will need to read it whole=20 anyway, and it would help greatly for things such as installers from CD=20 media. (Querying a bunch of packages over the network for their=20 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 :) --------------enigA1C266F0560A81607C164753 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGRDUXldnAQVacBcgRAq0lAJ49qzgZi6ZrnKc7vC7bRHvF6H2H0QCgz0oZ JQrFEeRfNytWdX9glK4CEC8= =pxIF -----END PGP SIGNATURE----- --------------enigA1C266F0560A81607C164753--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f21cen$iev$1>