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.
Regards,
--
Yann Dirson <[EMAIL PROTECTED]> | Why make M$-Bill richer & richer ?
debian-email: <[EMAIL PROTECTED]> | Support Debian GNU/Linux:
| Cheaper, more Powerful, more Stable !
http://www.altern.org/ydirson/ | Check <http://www.debian.org/>
