Re: RFC: Keywords instead of Section
Daniel Burrows wrote:
> On Sat, Nov 17, 2001 at 05:32:58PM -0800, Erik Steffl <firstname.lastname@example.org> was heard to say:
> > > Also, you should be aware that my experiments with loading control
> > > fields other than those that apt knows about (and hence caches) have
> > > yielded very poor performance on low-end systems.
> > it has very poor performance anyway and should be redesigned (for both
> > performance issues and to add flexibility)
> Sorry, that was unclear.
> I wasn't referring to my current categorization code.
> I was referring to the code that parses the "Task" header, which is a
> similar task (no pun) to what you seemed to be describing.
> OTOH, if you can find a way to speed it up significantly, that would
> be great. :)
sorry, I don't know what you are talking about, where are your
experiments with loading control fields?
in general: considering the amount of information about packages IMO
it's clear that we need a db-style system to hold the info, the two main
1 - do not assume everything can be loaded into memory
2 - index the data (performance)
as far as parsing goes I see no reason it should be much slower when
you have types and keywords instead of just keywords. it might be
problematic to try to use it using current data structures but I
assume/hope these will be replaced or at least significantly changed.
I mean current debian packaging system is close to perfect as far as
the data go (packages and data about packages are very good and
consistent) but IMO the underlying data structures and the programs
itslef could use a little bit of re-desing.
e.g. the low level (dkpg) should be completely independent from high
level (dselect, apt-get, aptitude) etc. each of the high level tools
should work on the same set of data (using the same low level API) so
that if you do e.g. apt-get update you do not have to do dselect update
to make dpkg (see the updated list of packages). etc.
IMO at this point the packaging system is at the level where we see
how it's used, what are the requirements (unlike during the time it was
designed where nobody knew how it would actually work in real life). so
it makes sense to use this info.