On Tue, 13 May 2008, Tim Kientzle wrote:
I think this is a really bad idea. The problem with the tools is
not with the files. It is that the files need to be parsed on each
run, often recursively, and your solution would not help at all.
Parsing one file isn't expensive; parsing several
Hi,
On Wed, May 14, 2008 at 05:55:33PM +0930, Daniel O'Connor wrote:
So long as you can tell it is corrupted..
It's also a drag from a user POV when the tool crashes because the DB is
hosed (seen in portupgrade a number of times)
The simplest way to achieve some measure of protection
On Sun, 11 May 2008 21:07:41 +0200, Jos Backus [EMAIL PROTECTED] wrote:
On Sun, May 11, 2008 at 06:38:25AM -0700, Garrett Cooper wrote:
+1. BDB is quite easy to corrupt...
If we're going to use a binary file format, please consider using SQLite
instead. It has the right license, a nice API
On Mon, May 12, 2008 at 05:12:56PM +0200, Anders Nore wrote:
On Sun, 11 May 2008 21:07:41 +0200, Jos Backus [EMAIL PROTECTED] wrote:
On Sun, May 11, 2008 at 06:38:25AM -0700, Garrett Cooper wrote:
+1. BDB is quite easy to corrupt...
If we're going to use a binary file format, please consider
On Mon, May 12, 2008 at 08:47:53AM -0700, Jeremy Chadwick wrote:
Secondly, the following FAQ entry and documentation from Mozilla is of
concern, specifically the last paragraph of the FAQ entry, since there
is ongoing work in the ports collection to support parallel building,
which would
On Mon, May 12, 2008 at 05:12:56PM +0200, Anders Nore wrote:
One of the reasons for using BDB is that it is in the base system, SQLite
however is not.
I'm aware of that. But I believe that the pain and suffering of importing and
maintaining SQLite in the base (that is, the cost) is outweighed
Hi,
On Fri, May 09, 2008 at 01:52:46PM +0200, Anders Nore wrote:
I'm working on adding .db support to the pkg_tools
I hope that you know that you're stepping into a hotly debated part of
the project... Good luck. My advice to you is to ignore any calls for
a 'complete rewrite' and to focus
I think this is a really bad idea. The problem with the tools is not
with the files. It is that the files need to be parsed on each run,
often recursively, and your solution would not help at all.
Parsing one file isn't expensive; parsing several hundred files
to find one bit of information
On May 9, 2008, at 5:43 AM, Joerg Sonnenberger wrote:
On Fri, May 09, 2008 at 01:52:46PM +0200, Anders Nore wrote:
I'm working on adding .db support to the pkg_tools( i.e. pkg_add,
pkg_info,
etc. ) as part of SoC 2008. The database api used is BerkeleyDB
that comes
with the base system
On Sun, May 11, 2008 at 06:38:25AM -0700, Garrett Cooper wrote:
+1. BDB is quite easy to corrupt...
If we're going to use a binary file format, please consider using SQLite
instead. It has the right license, a nice API (transactions!) and is robust
enough for yum to use it for a similar purpose.
Hi,
I'm working on adding .db support to the pkg_tools( i.e. pkg_add,
pkg_info, etc. ) as part of SoC 2008. The database api used is BerkeleyDB
that comes with the base system (/usr/src/include/db.h). BerkeleyDB is not
you're typical relational db, and can only save key/value pairs
On Fri, May 09, 2008 at 01:52:46PM +0200, Anders Nore wrote:
I'm working on adding .db support to the pkg_tools( i.e. pkg_add, pkg_info,
etc. ) as part of SoC 2008. The database api used is BerkeleyDB that comes
with the base system (/usr/src/include/db.h). BerkeleyDB is not you're
typical
On Friday 09 May 2008 13:52:46 Anders Nore wrote:
I'm working on adding .db support to the pkg_tools( i.e. pkg_add,
pkg_info, etc. ) as part of SoC 2008.
Is this gonna be optional?
One problem lies with the +* files which is scripts (e.g., +INSTALL,
+DEINSTALL). I've gotten some input
On Fri, 09 May 2008 14:43:08 +0200, Joerg Sonnenberger
[EMAIL PROTECTED] wrote:
On Fri, May 09, 2008 at 01:52:46PM +0200, Anders Nore wrote:
I'm working on adding .db support to the pkg_tools( i.e. pkg_add,
pkg_info,
etc. ) as part of SoC 2008. The database api used is BerkeleyDB
On Fri, May 09, 2008 at 06:50:10PM +0200, Anders Nore wrote:
Yes that would probably be bad for the database, but I'm sure one can
manage to get around this problem by copying it before changing the db and
delete the copy if it doesn't fail. At the next time executed it will check
for a
According to Anders Nore:
with the base system (/usr/src/include/db.h). BerkeleyDB is not you're
typical relational db, and can only save key/value pairs. The way I'm
thinking of storing information to the .db is to name the keys as the
directory names in /var/db/pkg. And save the +* files
On Fri, 09 May 2008 19:06:33 +0200, Joerg Sonnenberger
[EMAIL PROTECTED] wrote:
On Fri, May 09, 2008 at 06:50:10PM +0200, Anders Nore wrote:
Yes that would probably be bad for the database, but I'm sure one can
manage to get around this problem by copying it before changing the db
and
On Fri, May 09, 2008 at 07:54:40PM +0200, Anders Nore wrote:
You are probably right, but how would you store the key's? Is storing the
key as e.g., 'portname-1.2_3+CONTENT' a good solution?
I'd just use a different db file. I am not sure how much the following
applies to FreeBSD as pkg_install
18 matches
Mail list logo
