Re: "dselect" replacement team
On Sat, 12 Apr 1997, Jason Gunthorpe wrote:
> On Sat, 12 Apr 1997, Tom Lees wrote:
>
> > On Sat, 12 Apr 1997, Jason Gunthorpe wrote:
> >
> > > Sorry, I wasn't clear, there are two sets of the key/data pairs, one on a
> > > global level, the key is the package name the data is some kind of package
> > > data.
> > >
> > > Inside the data element there is a second database of key/string pairs
> > > which is the 'second tier' I was meaning.
> > >
> > > So you have Package\Tag=Value
> >
> > One of the major advantages of libdb is that you are not limited to only
> > strings in your database. All it gives you is a pointer to a bit of
> > memory, and the size of that - what you put in that can be whatever you
> > like, e.g. a struct. But you have to remember to set the size right, so
> > that the whole thing gets written out.
>
> Yeah, gnu's gdb also did this, It would be nice to have a full database
> that supported the 2 levels, but gdb/db will work in a pinch.
>
> This of course poses the question, how can we easially make the base
> library support cases were the entire list is in memory and were only the
> items that are required are loaded..
>
> If we simply load the database in full each time we fire up then it won't
> help anything at all.. Ideally progams like dpkg will only read the
> package descriptions that they absolutely require..
>
> Hm, I have some ideas on how to do that elagantly, I will have to ponder
> them somemore before they are presentable.
How about items in the database are only loaded when they are referenced
(explicitly or not).
--
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: