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.
Okay.
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
are
!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.
Okay.
> > 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.
Okay.
> > 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.
Okay.
Wanna be on the Committee?
Thomas
Reply to: