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

Re: RFC: Keywords instead of Section

On Sat, 2001-11-17 at 07:53, Erich Schubert wrote:
> 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.


My suggestion to the Committee is that it adopt a set of
keywords consisting of parameter-type/parameter-value pairs,
as I described earlier.

> So if they define "gpl" as keyword for Applications unter GPL Licence,
> that is just what i was thinking of.

Okay, we agree.  My opinion is that "license:gpl" makes
the sense of the keyword more obvious.  It is much clearer
in some other cases.  The current "x11" section is full
of programs with x11 user-interfaces because people didn't
understand or remember that this section was supposed to
be for X servers and related support software only.  If
the keyword the Committee adopts is "service:x11" rather 
than just "x11" then this is much less likely to happen.

> 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!).

I agree.

> > 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?

Packages are assigned one or more keywords according to how
well those keywords suit the package.  I just don't see the
use of classifying packages according to whether they are
"special" or not.  What is that supposed to mean?

I suppose the Committee might define the word to be of some use.
Perhaps it will be defined to mean 'package that the Committee
had a hard time classifying'.  Then if the novice user is
interested in those packages that the Committee had a hard
time classifying, he can select the 'special' keyword.
Sounds dumb to me, but Committees often do pretty dumb things.

> > 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
> class".

Fitting in where?  You are forgetting that under the proposal
we no longer have mutually exclusive classes; and with the
pool we no longer _have_ to find a section to put a package in.

It makes a _bit_ more sense to use 'other' as one of a range
of keywords of the same type.  E.g., 
   license:gpl, license:bsd, license:prop, license:other
However, "license:other" still doesn't serve any particular
purpose.  I can always do without it by asking for packages that
    !license:gpl && !license:bsd && !license:prop
or whatever I really want.  ':other' only has meaning relative to
the other keywords of that type; thus its meaning changes as
keywords of that type are added.

> 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.

Agreed.  It's probably better to have just one new field.
However, the other way could be made to work, because I think
that there will be a fairly small number of keyword types.

> > 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.

I will!  :)

I think we're understanding each other now.

> > 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.


Wanna be on the Committee?


Reply to: