Date: Sat, 12 May 2007 13:27:45 +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: <f248bp$akg$1@sea.gmane.org> In-Reply-To: <46450EE1.300@hcl-club.lu> References: <200705102105.27271.blackdragon@highveldmail.co.za> <f20c8u$htp$1@sea.gmane.org> <46450EE1.300@hcl-club.lu>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCFE6EDE01F8D722223639129 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jona Joachim wrote: > I don't think it would be a good idea to use SQLite for this purpose. > First of all using the file system is the Unix way of doing things. It'= s > efficient and easy to use, it transparent and user friendly. You can > simply run vi to inspect a text file but you can't do this which an > sqlite database. You have to learn sqlite to do it. That particular barrier to entry / learning curve is very shallow. In the end, it's a tradeoff between speed in the general case and ease of use (from the developer side), vs convenience in the extreme cases. > Furthermore I don't think the pkg_* tools are slow. They are quite fast= > IMO. If you let pkg_info print the entire list of installed ports it's > only slow because of your line-buffered console. Just redirect the > output to a file and you'll see that it's blazing fast. If I compare it= Err, nope. :) I see Eric has provided the numbers. > for example to Debians apt-get/apt-cache commands it's much faster. AFAIK Debian has the same dichotomy FreeBSD has: a tree of text files used by dpkg, and a binary database (cache) used by apt. > portupgrade is very slow, that's true. First of all it's written in Rub= y > which is not one of the fastest languages but there is another thing > that slows it down considerably, which is rebuilding its database. In my (limited) experience, this sort of task should not depend much on the speed of the language. The most CPU-intensive task portupgrade does is resolving dependencies, and on a running system this is a DAG forest of about 500 nodes. I know portupgrade has some highly unoptimal code in it (if I understand the code correctly, there's a brute force check for cyclic dependancies in it!), but still, in itself, I think the choice of Ruby isn't performance-critical. > Furthermore I think it would be a very bad idea to include sqlite in > base. There is already a lot of third party stuff in base. The > philosophy of the BSDs is to provide and maintain an entire OS. This is= > quite the opposite of how a GNU/Linux system is designed. Both ways hav= e > their pros and cons. An advantage of the BSD way of doing things is tha= t > the developers know the code very well and have control over the qualit= y > of the code. If you include 3rd party software into the FreeBSD base > system you make the FreeBSD project depend on the people that wrote tha= t > code. Of course you could fork it but the FreeBSD developers are not > necessarily familiar with the code. Security patches would have to be > merged all the time and a lot of communication between the two projects= > is needed. I think this line of reasoning was made invalid by the continuing inclusion of sendmail, bind, expat (xml parser!), etc. Not that I don't realize this increases the burden on maintainability, but including a "frozen" branch of a library, which is supported, but won't be changed for ages isn't going to increase it much. Offloading much of the "smarts" to a database would also permit easier reimplementation of portupgrade-like tool in C, since the heavy parsing / regex facilities scripting languages offer won't be used as much. But yes, it's a heavy departure from "the unix way". > I think the best way to go would be to use only folder hierarchies and > text files and write a libary in C that provides portupgrade > functionality. The code under src/usr.sbin/pkg_install/lib/ would be a > good base for this. Then you could use a frontend program that makes us= e > of this library. This frontend could be a CLI program or a GUI based > program. The issue in this thread (at least for me) is performance and reliability, and creating a C wrapper around the current situation won't solve neither. --------------enigCFE6EDE01F8D722223639129 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.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGRaS3ldnAQVacBcgRAsXCAKCLDd+4As/BZ7ArsIhQkjSw/Pqz/ACgyHXT VOfLZaByz26fAic+QVs52Mk= =kY0l -----END PGP SIGNATURE----- --------------enigCFE6EDE01F8D722223639129--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f248bp$akg$1>