New FreeBSD package system (a.k.a. Daemon Package System (dps))

[Julian Elischer]

Ivan Voras wrote:
> 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).

ok, let me give you some words that come from the wisdom of having done this 
for 30 years.

"Use an SQL DB file for this over my dead body"..

Now having said that, I need to modify it a bit and explain.

Explanation:
 The number of times I've gone into /var/db/pkg to read the files to 
 figure out what the "fsck" is going on, is very large.
 It is also possible to delete files and edit them.
 This is very important to me in this imperfect world when the pkg 
 system gets things wrong (oh no, don't tell me that the new pkg system never
 gets things wrong.. like including a file in 2 packages).

Modification:
 Now, I have no objection to a DB file of some sort IF (and only if)
 it is somehow rebuildable from a text base which is kept somewhere,
 like the password database is done. but PLEASE, NO SQL in the base system!




> 
> - A quick test confirms that the current bsdtar will happily ignore any
> extra data at the end of a tgz/tbz archive, so package metadata can be
> embedded there, thus conserving existing infrastructure and being fast
> to parse. I suggest encoding this metadata in a sane and easy to parse
> XML structure.
> 
> I cannot currently actively participate in implementing proposed things,
> but I can give advice on sqlite, database and xml schemas if anyone
> wants to...
> 
>