Re: Packaging system improvements
Behan Webster writes:
> Think of how a search mechanism works on the web. If a web page
> provides keywords for search system, they don't classify what
> each keyword has to do with, it just lists those keywords the
> author thinks are relevant to the document at hand.
Yes, it might be how it's done. Is it really an excuse ;-) ? [just kidding]
> > I still advocate adding more fields, like "Interface:", to the
> > existing "Section:", for addressing such problems. Then you'll have a
> > "X11" keyword as Interface, and a "X11" keyword as Section; this seems
> > to me much more intuitive...
>
> Why do you need to make the distinction?
It's surely not a need, but I think it should be good for something
...though I must admit my arguments are getting less and less
powerful :(
> The current Section X11
> does not. In the current X11 directory there are both packages
> to run an X11 server and other packages that just have an X11
> interface. There are a lot of packages scattered all over the
> debian hierarchy that argually belong in the X11 directory, and
> yet don't.
Yes, and I find that awful. That's one of the reasons that made me
propose that...
> Personally, I would specify the following keywords for the
> following packages (off the top of my head):
>
> xbase: X11, X11R6
Yes, why not. But this is just a convention about not using "X11" for
the "Section" I proposed, but for the "Interface". I like it.
> The point of a single new Keywords header is that people can add any
> keyword they wish (whether their own, or from a list of accepted
> Debian keywords).
[...]
> By letting deity deal with how keywords are presented to the user,
> we have a great deal of flexibility of adding new accepted debian
> keywords or groupings of keywords without having to go back and
> change the header fields on every package in Debian.
>
> By using a rigid design of extracting the precise meaning of a
> Keyword based on the field it's in, all flexibility is lost:
Then why not take advantages of both approaches: additionnal
section-headers give some expressive power that keywods can hardly
permit, and keywords can be used when this additionnal power is not
needed.
> developpers would not be able to add their own keywords until a new
> heading has been agreed upon (at which point they would have to
> re-upload their packages), and the UI would not have the flexibility
> to group keywords as it sees fit.
Why wouldn't it ? I proposed some time ago to add new headers on a
common-prefix basis; thus all fields starting with the same string
(that would have to be understood by the UI) would be available to be
handled the same way as, say, "Section".
This would even allow users to add their own fields, just like the
Keywords field will allow them to add new keywords; they would not
only be able to add new keywords, but also new "classes of keywords".
> btw, keywords will not only be provided by the Keywords header but
> also from most of the existing headers (Section/Priority/Recommends/
> Suggests/etc.)
OK, I fully agree with that (see above ;)
One more suggestion about Keywords, be they in their own field or
spread all around control files:
What about allowing subclassing these keywords ? That would maybe
be useful for Interfaces, with thinks like "X11/Motif" or
"X11/Tk"... especially new user won't knows what Motif and Tk are
[yes, they can search and read, but why searching for this ?]
--
Yann Dirson <dirson@univ-mlv.fr>
alt-email:<ydirson@a2points.com>
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: