Re: Getting rid of section "base" ?
On Fri, Dec 03, 1999 at 12:51:37PM +0100, Yann Dirson was heard to say:
> > > Daniel Burrows writes:
> > > > Secondly and more importantly, the current sectioning system is holding back
> > > > the more advanced interfaces
> > >
> > > I didn't follow such discussions - can you please give examples for
> > > this ?
> >
> > This may have been a slightly grandiose claim -- but basically, no apt
> > interface can be built with the current tools in which the packages are
> > organized into a reasonable hierarchy, because there *is* no information in
> > a package telling what should be done with it. The best thing you could
> > do would be to create your own listing of each package with a reasonable
> > section for it and work from that -- a hacky solution, and one that doesn't
> > 'scale' well (since you have to classify every package and keep up with the
> > dozens of packages that get added each week)
>
> 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? :)
> > 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 :)
> > -- 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 :)
Daniel
--
Whoever fights monsters should see to it that in the process he does not
become a monster. And when you look into an abyss, the abyss also looks
into you.
-- Friedrich Nietzsche
Reply to: