ports system woes

[Michel Talon]

Garrett Cooper wrote:

> We're rehashing the discussion made last year around June - July.

Indeed.

> 
> We came to the conclusion that BDB should be used, as no other DB  
> backend / API exists in the base system (currently), and porting  
> SQLLite (while nice) appeared to be non-trivial to port 

Are you kidding? The patch files are totally trivial modifications,
to include stdlib.h. The bigger one is in Makefile.in to take into
account these ones.

> and got a lot  of unhappy responses from folks.

This is true. A lot of people expressed aversion against SQL, by itself.
However it should not be bad to evaluate a solution based on BerkeleyDB,
another one on sqlite, and chose based on merit, not on aversions. What
is the simplest to use by the programmer writing pkg_* tools, what
offers the best performance and data organization, etc. At the moment
portupgrade uses a BerkeleyDB, are you convinced by the result? In
particular an obvious fact is that there are constant troubles when the
DB version number changes or the ruby adapter changes. One may expect
that no such problems will occur with a very stable and standardized
language like it is offered by sqlite. If this argument is correct, it
is quite strong, in my opinion, because i don't expect much performance
difference otherwise. There is also the question of atomicity and
locking which is particularly important in this context. It would be
useful to compare what the BdB in the base system has to offer
compared to sqlite - because comparing to what the most recent versions
of bdb in the ports can do has a different bearing on the question.

-- 

Michel TALON