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

Re: RFC: Keywords instead of Section

> > That is correct, but with multiple keywords this works just fine, select
> > keywords "X11" and "client", or "x11" and "server", and there you go.
> "x11" & "client" might match, e.g., client tracking programs that
> have X11 interfaces.  The benefit of defined typing is that

incorrect. this is NOT a Full-Text-Search, and the keyword "client" is
for "client applications in a client-server model", not for things such
as client tracking (i'd suggest "customer management" or a keyword like
that for this)
Remember: the keywords are EDITED, not automatically generated!

> type that may be used.  Once we adopt the "ui:" type, it is
> natural to adopt "ui:x11", "ui:console", "ui:none" descriptors.

that's just cosmetic, too. Of course we can call the keywords any way we
want. I like the way "ui:x11", too. But i would not restrict the
implementation to treating this specially.

> Perhaps you mean that the type name need not be part of
> the descriptor.  True, but including the type name has
> benefits.  You do it yourself in some of your examples.

I'm talking about implementation, not about using them. I see no need at
all to treat this specially.

> What a classification system has the opportunity to do better
> than a text search is to define the meanings of the keywords
> very strictly.  This is what typing does.  Making the type
> name part of the descriptor is optional, but I think it is a
> good idea because it makes the sense of the keyword obvious.
> It also allows the same keyword to be used in different senses:
> e.g., "ui:x11" vs. "server:x11"; "license:gpl" vs. "topic:gpl";
> etc.

All this does NOT belong into the implenation. I do not want to change a
single line of code if someone want's to redo all classification and
implement another sceme.
All this is a decicion of the "Keyword Commitee", and they are - as i
wrote before - to definie the keywords and their meaning.
So if they define "gpl" as keyword for Applications unter GPL Licence,
that is just what i was thinking of. But this is the Commitee's Choice
and has to be kept out of the implementation, so it can easily be
changed (think of a company doing a Debian-Based Distro not caring at
all about Licence's - they might want to leave that away completely.
Other's might want to do a completely different categoriation!).

> As a description, 'special' or 'other' is too vague to be
> useful.  One might as well omit it entirely.

So the packages not fitting into a category are not found by novices?

> If one is resorting to classifying a package as "special", it
> means that the classification scheme needs to be enhanced.

No. It means "there are to few packages fitting in here to add a new

> Freshmeat/SourceForge types are: Development-Status, Environment,
> Intended-Audience, License, Programming-Language, Topic.

Which are basically all equal in the database and are assigned Integer
Numbers from the same namespace. This Categorization of Keywords is
purely cosmetic in the user interface (i think).

> I agree that this is not a good set of types.  The "Topic"
> type is too broad, for example.

That is exactly why i do not want to implement such an hierarchy in the
package system itself, this belongs into the user interface, where
people can have multiple, differing implementations.

> What's the problem?  Lots of other fields are lists too.
> (Depends:, etc.)

But "Depends:" is well defined, where your way requirez _dozens_ of
different additional fields, making parsing much more difficult.
p.E. package managers not knowing what your "Licence:" Field is will not
provide this way of selecting Packages to their users.
So if we decide to add another Field (like Intended-Audience:) ALL
Package Managers will have to be modified! Thats EVIL.

> > Which is basically my proposal.
> > "Keywords: client, stable, X11, console, audience-user, gpl, devel-c,
> > devel-python, cooking, sex"
> > 
> > Without treating any keyword special, unless the user prefers to do so.
> Our proposals are different.  To search for all "License:GPL"
> packages is much more specific than to search for all packages
> that have something to do with the GPL.  The latter group may

You didn't understand my proposal.
I'm NOT talking about a full-text-search (which is already provided by
apt-cache search and most package managers) and which would indeed find
all Packages having to do anything with gpl.

The keywords are to be edited and well defined by a "Keyword Commitee",
and it's their job to make good keywords, not the software's.

> include documentation packages having to do with GPL, or 
> programs used to ensure GPL compliance, or whatnot.  You
> suggest that this can be remedied by combining keywords,

It can, of course.

> but no conjunction of keywords will allow you to search for
> all and only those packages whose license _is_ the GPL.

If the keyword is defined to be "gpl-licenced programs only", this is
exactly what you want, if it's about "anything to do with the gpl"
(which might not be too useful, use full-text-search for that!)
blame the keyword commitee.

> Unless you have a "license-gpl" keyword, of course.  In which
> case it makes sense to have a "license-bsd" keyword, and ...

Correct. And a licence-nonfree keyword of course, so i can easily
drop all non-free software from my selection.

> lo and behold, you have developed a typed keyword classification
> scheme!  But ad hoc, instead of systematically.

I havn't developed ANY keyword classification scheme at all. I provided
some idea's of good keywords and called for a Keyword Commitee to do a
proper selection and definition of keywords.


Reply to: