New FreeBSD package system (a.k.a. Daemon Package System (dps))
anderson at freebsd.org
Sat May 12 01:19:59 UTC 2007
On 05/11/07 19:48, Jona Joachim wrote:
> 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
Hmm.. Tried to stay out of this whole 'discussion', but, I just disagree
here flat out.
# time pkg_info > /dev/null
During that entire time, my hard disk was being hammered. Blazing
fast.. ? Maybe I need a 15k RPM SCSI disk, or something.
Anyway, to me, a file system *IS* a database, and if it's slow, it
probably could be used better, and get much better performance. I've
seen some very ingenious file system layouts that have several million
records easily used on slow systems, and it works pretty well.
[..snip warm fuzzies..]
> 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
That's not a bad idea, if it isn't already available somewhere.
More information about the freebsd-hackers