Re: RFC: Keywords instead of Section
Daniel Burrows wrote:
> On Sat, Nov 17, 2001 at 04:34:51PM -0800, Erik Steffl <email@example.com> was heard to say:
> > > No. It means "there are to few packages fitting in here to add a new
> > > class".
> > that's not a reason not to have a class. why would a class would have
> > to have certain number of packages? If it's distinct enough there should
> > be a class for it. e.g. if we suddenly get a new ui type there might be
> > only handlful (or none!) programs using it, e.g. for berlin. that does
> > not mean there should not be a category for it.
> The problem with this is that then we move from having a confusingly
> large number of packages to having a confusingly large number of
> classes, each containing one or two packages. This will help keyword
> searches, perhaps, but will be actively detrimental to people trying to
> get an overview of available packages.
well, there's no way to have fewer when you have a lot but it can at
least be sensibly organized. the decisions have to be made carefully but
there's no reason to simply avoid decision and put programs into 'other'
as I mentioned in other email we might need hierarchical system of
types anyway - that way you would have reasonable number of types on
then there's a problem of having number of keywords of given type. so
we might want to have hierarchical system of keywords of certain types
as well (i.e. ui would be x11->qt, x11->gnome etc. instead of just plain
x11). this can be solved by having another type, i.e. toolkit or
something like that...
this has to be thought over in lot more details of course so that it
is really usable... but that's the way to go to make it usefull.
> > > p.E. package managers not knowing what your "Licence:" Field is will not
> > > provide this way of selecting Packages to their users.
> > why not? that's why you have defined set of types. user can query by
> > any type, the package system does not have to be specifically aware of
> > it. Also, user can see the list of all types, again, package system does
> > not have to be aware of them - it's just data.
> I think he was objecting to the implementation as separate fields in
> the control file; you could perhaps allow the user to select on a
> specially-defined control field, but that requires that they know the
> field name ahead of time. (ick)
of course, there would be a list of types and user could see it and
query based on these. the whole point is to have types and the typed
> 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)