[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "dselect" replacement team



On Fri, 11 Apr 1997, Jason Gunthorpe wrote:

> On Fri, 11 Apr 1997, Martin Schulze wrote:
> 
> > On Apr 11, Jason Gunthorpe wrote
> > 
> > > > Much has to be done... I'm in the process of creating a list of them...
> > > I'd be interested in this list when you get done..
> > If no one stops me it'll be placed in the doc directory on our ftp
> > server.
> Great!

Please announce this when you do it (exact file location, etc.). Or, see
the separate post about a "debian-answers" list I'm making.

> > Sure, a binary format would be faster.  But I don't think that it would
> > be that fast that we should lose our ascii files.  Just believe the only
> > file for debian which is not plain ascii is .deb.
> 
> That was why I was doing those timings, reading a text file ins't exactly
> deadly slow. 

But searching a binary-sorted tree is always guarunteed to be faster. And
considering how fast the number of packages has been growing, it may well
become a problem in the not-too-distant future.

> > All other files like debian/rules, debian/control, configuration files
> > etc. etc. are plain ascii files.  I have a very strong feeling for 
> > keeping them.
> 
> Of course, there are too many reasons to stick with simple parsed ascii.

Most of which are probably "tradition", or "compatibility", which we
should eventually be able to eliminate.

> > > Libdb might be a good idea to implement in a cache mode, ie have status.db
> > > which is a mirror of status in libdb format, then if status is changed the
> > > db is rebuilt.
> > Hmm, I have a very simple idea.
> > 
> > libdpkg looks for status and status.db.  If the latter exist and has the
> > same date or newer it is taken, otherwise the plain ascii file is used
> > and a new .db is generated.  What about this?
> 
> Exactly! Thats what I call a cache file.

OTOH, it may be better to eventually aim to support the text-file through
a separate utilty, which can extract and re-build the database. dpkg-ftp,
and others would have to be updated to use the database first though.

But agreed, a cache-file is a good idea, since many more programs want
read-access to the database than write. (Only dpkg and dselect want to
write, as far as I am aware).

Hmmm, I just had a thought. We _NEED_ some kind of perl interface to the
libdpkg, for dpkg-ftp, etc. Arggh.

> I will take a look at libdb's docs right now I guess..

>From the docs I read earlier today (dbopen.3, hash.3, btree.3), it seems
the most appropriate method is BTREE.

Will it be write-cached as well? :)

-- 
Tom Lees <tom@lpsg.demon.co.uk>			http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E  B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)


Reply to: