Re: Packaging system improvements
Brian White writes:
> > Yes, but a keyword list provides very poor structure for this type of
> > information. Providing several concurent ways of classifying the
> > pacakges will give better structure, and thus will be easier (more
> > straightforward) to search.
> >
> > I suggest (again) at least the following fields:
> >
> > Interface: (eg. X11, console, tty, stdio)
> > MainFonctionnality: (eg. editors, devel/compilers,
> > games/arcade/tetris-like, etc.)
> > DistPolicy: (eg. free/GPL, free/PD, free/custom,
> > restricted/non-profit, etc.)
>
> The keyword list provides the exact same thing but doesn't bother to
> break it down into three different headings.
Yes. And plain TeX provides the exact same thing as LaTeX
(ie. well-looking documents), and there's nothing you can do in LaTeX
that you can't in plan TeX, but doesn't bother to add all these
superfluous declarations on top of your document...
Think about it... we call this *STRUCTURE* !
If that's not sufficient, just think about structured programming
compared to BASIC, etc. In all these cases, yes, there are
some additionnal (structural) information to provide to the
program. When you first use it, you often go "why such a mess ?
Basic/plain TeX/keywords could do this without such a fuss!". But when
you got used to the additionnal information conveyed by a better
*structuration of the information*, you usually don't look at those
ancestors in the same way...
> Multiple headings really
> doesn't gain anything and makes it less extensible in the future.
Then how are you going to handle with just keywords the fact that
'X11' is an interface-type, and also a section (containing xlib,
xservers, etc.) ?
We could use 2 different keywords, but that would not be intuitive for
the user. If he asks for 'X11' and gets nothing (because we threw this
keyword away because ambiguous), it will be bad; if he wanted one of
the 2 alternatives and gets the other one (because then we'll have to
choose), it will be bad as well.
So, unless there is a *really* good reason not to do so, I advocate
not to use a single Keywords field, but to add several fields.
You argument about the problem to handle new fields with dpkg don't
hold either IMHO: we could just tell dpkg to handle all fields
starting with, say "Categ-", in a consistant way. Then just
modifications in a file (from the distribution ?) will allow to
extend its vocabulary, to get fields "Categ-section",
"Categ-interface", "Categ-dist-policy", etc.
I insist. If there was to be a vote on this, I'd vote against
structureless keywords. This solution may be seen as just "structured
keywords"; we could even put several things in "Categ-section", but I
don't really thing it'd be wise.
Regards,
--
Yann Dirson <dirson@univ-mlv.fr>
http://monge.univ-mlv.fr/~dirson
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: