Re: Packaging system improvements
Yann Dirson wrote:
>
> Behan Webster writes:
> > 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...
I'll agree that it's not ideal, but it's what we have now, and what
I had to build on. This system needs to be somewhat backwards
compatible.
> > 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.
I don't think I'm succeeding at communicating my ideas to you.
Let me try again.
The way things are planned currently, keywords don't have any express
meaning. It doesn't matter where they are read from (Keywords/Section/
Priority/etc) they are just keywords. They are concepts that describe
what the package does.
In fact the only reason keywords are read from headers other than just
Keywords: is that I was building on an existing standard. If this
informatoin wasn't needed for the rest of the packaging system, I'd
prefer all these things to be _only_ listed as keywords.
A keyword of "required" will pretty much mean that the package is
a required package despite whether or not it is listed specifically
in the Prioriry Header. In the same way, a keyword of "X11" pretty
much means the package has something to do with X11, whether or not
it's listed in Section header.
Doing things in this way is quite nice because it means, for instance,
that we can extend how things are classified by Section. There are
quite a few packages that are X11 programs, but are in other sections
because they fit there a bit better (editors, graphics, etc.). By
simply adding a keyword of X11 to these package's keyword list they
effectively have a secondary Section classification. Then, for
instance if a user decides they don't want X11, but they do want
editors on their server, they don't have to wade through xcoral,
xwpe, etc. Obviously, if they don't want X11, their not going to
want to install these X11 editors, so why bother offering them to
the user?
Assigning an expanded meaning to a Keyword just because of which header
it was found in don't gain you that much, but it does complicate how
keywords are shown to the user. With unique keywords, their meanings
become quite obvious. Having keywords that have multiple meanings means
that these meanings must be made evident whereever they are shown in
the UI. Now, on some screens this will be easy because it will be
desireable to group keywords with common meanings. On other screens
(screens that have limited space), it is more desireable to just list
the keywords (the tabbed keyword window comes to mind). On these
smaller screens there isn't a lot of space to list a qualifier for
every keyword.
> > 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.
Because, each time you add a header you are changing the deb
packaging standards. It is desireable to minimize this change.
One of the complaints I've heard leveled at dpkg is it always in a
constant state of flux. One of the things I'm trying to do with
"Keywords" is provide a mechanism such that more information can be
added to a package without defining a new header. If we minimize
change to the deb format, I believe that it will become a much more
desireable packaging standard to both developpers and companies.
The problem with adding new headers is that it is desirable to have
everyone reupload their packages with the new packaging standards.
The nice thing with a single Keywords header is that new information
(in the form of keywords) can be added progressively with out forcing
a change to what headers need to be provided.
> > 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".
Because you are still changing the packaging standard by doing so.
Not only that, but in my opinion, you are adding unneeded complexity
to a mechanism that can be accomplished in a much simpler fashion.
It is very desirable to follow the KISS theory.
> 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 ?]
This is a pretty good idea, but only for keywords in the Keywords
header. The other headers have established meanings.
I was thinking people would use compound keywords like this, except
I was expecting people to use a '-' or '_' to seperate the words.
In the specific example you give though, there is no reason not to
use 2 keywords: "X11" and "Motif". Combining them doesn't give you
any more meaning than keeping them seperate. Both these keywords
are not likely to have any other meanings.
Thank you for your interest.
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
--
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: