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

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 :)


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: