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

Sectionning overhaul (Was: Getting rid of section "base" ?)

Note: I followup to deb-dev where this thread is (I think) more
appropriate.  I think I'll summarize the past events, but that will
probably wait till monday.  The curious one will find the beginning of
the thread in the debian-project archive on www.debian.org - it is
refered to from the Debian Weekly News dated 30th November.

Daniel Burrows writes:
 > > What do you mean by "there *is* no information in a package telling
 > > what should be done with it" ?  Are you talking about infos currently
 > > put in the Packages files ?  In this case isn't it just a matter of
 > > adding new fields ?
 >   ?
 >   I mean that you can't get a fine-grained categorization from the info in the
 > Packages files.  And yes, you just have to add more fields.  The problem is
 > that no-one has yet.  Isn't that what we're talking about, or did I lose track
 > of what was going on? :)

Nope, it seems it was me misunderstanding part of what you said - it
really seems we agree on this point.

 > >  >   Actually, there is a good reason: very few people want to install a library
 > >  > except to fulfill dependencies, so displaying libraries along with everything
 > >  > else is just going to force people to weed out additional packages they don't
 > >  > care about.
 > > 
 > > If we add something like the Nature tag I suggested, it's as easy as
 > > filtering out "Nature: library".  The old "libs" section would not
 > > have to be reconstructed as a section.
 >   I meant in dselect, which (presumably) doesn't know about anything but
 > sections.  If it was modified to take full advantage of the new tags, so much
 > the better :)

Thinking backward, although it still does not strike me as useful to
reconstruct "libs" because I think looking for libs in other sections
would be acceptable, I can see the need for this reconstruction for
the "devel" section.

 > >  > -- I still don't
 > >  > see why Interface: daemon (or Interface: server) isn't a good idea if the
 > >  > program itself has no real interface (ie, it's just a daemon) ----
 > >  > Interface: none might be even better, though (thinking about math libraries
 > >  > vs GTK+, etc)
 > > 
 > > Because, being consistent in handling "Nature: application" and
 > > file-formats, and "Nature: server" and protocols may allow us to use
 > > only one mechanism.
 >   Could be.
 > > However the words I have chosen ("language", "translator") may not be
 > > really adequate.  Maybe "script" and "interpreter" would be more close
 > > to be universal (a data file is a "script" for its "interpreter"
 > > reader program, a binary executable is a "script" for its
 > > "interpreter" processor/board/os, a message in a network protocol is a
 > > "script" for the "interpreter" server or client).  Well... here it
 > > makes it obvious that the client/server issue is a bit different.  The
 > > model still needs to be finetuned to make it generic enough - hope
 > > that won't bloat it :|
 >   I think it's starting to make sense to me :)

I'll probably take some time to put that on a web page.

Yann Dirson    <ydirson@altern.org> |    Why make M$-Bill richer & richer ?
debian-email:   <dirson@debian.org> |   Support Debian GNU/Linux:
                                    | Cheaper, more Powerful, more Stable !
http://www.altern.org/ydirson/      | Check <http://www.debian.org/>

Reply to: