DPS Initial Ideas

['Michel Talon']

On Mon, May 14, 2007 at 05:48:38PM +0100, Tom Evans wrote:
> On Mon, 2007-05-14 at 10:25 +0200, 'Michel Talon' wrote:
> > Where is this huge increase in size?
> > Admittedly, i have not created indexes, etc.
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Compare this to the portsdb created by portupgrade from the same INDEX-6
> > 
> > niobe% ls -lh /usr/ports/INDEX-6.db
> > -rw-r--r--  1 root  wheel    21M 16 fév 13:36 /usr/ports/INDEX-6.db
> > 
> > Surprise, surprise, the BerkeleyDB suddenly appears less glorious.
> 
> Your index has no indices, and you wonder why it is smaller?

I am really tired answering questions about straw man,
misrepresentations of my position, and so on. I don't advocate using
XML, nor java, nor java tools nor anything of this sort. I am only
claiming that SQLite does a better job than a BerkeleyDB for the 
precise mission that it seems the BerkeleyDB is programmed in the SOC.

As to the question of indices i am the one who pointed out there are no
indices, so there is little merit inventing this new objection. 
Moreover the objection is completely bogus, because SQLite creates the
index in memory. After the following command
sqlite> create index path_ind on index6(path);
(i have created an index on origins, the only question of interest)
the size of the database doesn't change at all! It remains twice smaller
than the BerkeleyDB. But the memory consumption augments. here are the
values before and after creation of index:

USER     PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
michel  1174  0,0  0,2  2984  2324  p2  I+   21:03     0:00,01 sqlite3
michel  1174  0,0  0,6  6728  6068  p2  S+   21:03     0:00,34 sqlite3

By the way, i don't concern myself with the problem of accelerating
package registration or similar stuff. Indeed most of these problems
can easily be solved by some optimizations in the makefile and
parallelism. 

The true problem, as Kris said, is the problem of upgrading an
installation in a reasonable time -that is, not several days- and with
*total* reliability. None of present FreeBSD tools do that, while it is
common place with Debian. This is an extremely difficult problem 
in the FreeBSD context as des said, and i am certainly not able to solve
it. But at least i have researched the question and written some code.
It is perfectly obvious that most of the bikesheds in this thread are 
due to perfect ignorance of the subject, which could be remedied
reading:
http://www.lpthe.jussieu.fr/~talon/freebsdports.html
and the small SQLite documentation at:
http://www.sqlite.org/lang.html




-- 

Michel TALON