From owner-freebsd-hackers@FreeBSD.ORG Sat May 12 01:10:56 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A64916A403 for ; Sat, 12 May 2007 01:10:56 +0000 (UTC) (envelope-from jaj@hcl-club.lu) Received: from 0b10111.de (hcl-club.lu [62.75.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id C14CB13C45D for ; Sat, 12 May 2007 01:10:55 +0000 (UTC) (envelope-from jaj@hcl-club.lu) Received: from [192.168.1.100] (ip-83-99-95-13.dyn.luxdsl.pt.lu [83.99.95.13]) by 0b10111.de (Postfix) with ESMTP id 1147C872C2E2; Sat, 12 May 2007 02:51:56 +0200 (CEST) Message-ID: <46450EE1.300@hcl-club.lu> Date: Sat, 12 May 2007 02:48:33 +0200 From: Jona Joachim User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ivan Voras References: <200705102105.27271.blackdragon@highveldmail.co.za> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 12 May 2007 01:11:40 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: New FreeBSD package system (a.k.a. Daemon Package System (dps)) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2007 01:10:56 -0000 Ivan Voras a écrit : > David Naylor wrote: >> Dear Jordan >> >> Recently I stumbled across a document you wrote in 2001, entitled "FreeBSD >> installation and package tools, past, present and future". I find FreeBSD >> appealing and I would like to contribute it its success, and as your article >> describes, the installation and packaging system is lacking. Since the >> installation system is being tackled under a SoC project I am hoping to give >> the packaging system a go. > > I've just read the document, and since I was also thinking about the > ports/packages system lately, here are a few random ideas: > > - I think it's time to give up on using BDB+directory tree full of text > files for storing the installed packages database, and I propose all of > this be replaced by a single SQLite database. SQLite is public domain > (can be slurped into base system), embeddable, stores all data in a > single file, lightweight, fast, and can be used to do fancy things such > 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. And the upcoming X11/X.Org 7.2 with cca 400 packages (which is > in itself horrible just for a X11 system) will make it unbearable (also > portupgrade which already looks slower by the day). 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. 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 for example to Debians apt-get/apt-cache commands it's much faster. portupgrade is very slow, that's true. First of all it's written in Ruby which is not one of the fastest languages but there is another thing that slows it down considerably, which is rebuilding its database. 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 have their pros and cons. An advantage of the BSD way of doing things is that the developers know the code very well and have control over the quality 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 that 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 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 use of this library. This frontend could be a CLI program or a GUI based program. Best regards, Jona