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

Re: Getting rid of section "base" ?

Daniel Burrows writes:
 > > I don't intend to map this into a (file-)hierarchy.  Till now I
 > > thought of 2 approaches:
 > > 
 > > * Using virtual-packages like "gif-language" and "gif-png-translator",
 > > and have frontends parse those virtual-package names to, say, provide
 > > a "png-screen-translator" (or probably better "png-reader") and a
 > > "gif-png-translator" when asked for a "gif-reader".
 > > 
 > > * Using a new field ("Translates" ?) used in the same way that above,
 > > using a syntax like "gif:png" for a translator, "png:" for a reader,
 > > and maybe ":gif" for a pure writer (eg. fractal-drawing programs, and
 > > such programs for which "source" material is encoded into the
 > > executable).
 >   Hm, ok.  I'll have to think about whether I can come up with a reasonable
 > interface for something like this.


* a special display showing known "languages", maybe organized in a
hierachical way ("fileformats/images/png", "executables/java",
"protocol/ip/tcp/ftp", ...), each showing a possible solutions.

* possible solutions could be splitted in such a way:

+- xv
+- imagemagick
+- via GIF
|  +- converters
|  |  ` giftopng
|  +- gifviewer
|  +- othergifviewer
|  `- via PBM
|     ...
`- via PBM

 > > 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 ?

 > >  > it would be possible to just look at the first level
 > >  > of the hierarchy (possibly using additional information to, eg, reconstruct
 > >  > "libs")
 > > 
 > > Well, I don't really see the interest in reconstructing
 > > "libs"... (well, except if you need a lib, but then I don't think
 > > you're in a worse situation than when you need, say, a perl module :).
 >   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.

 > >  >   Hmm.  Most daemons don't come packaged with a client, and clients can use
 > >  > different interfaces (just look at the different WWW or FTP clients..)
 > > 
 > > Yes, that's right.  The idea would be that the sysadmin could tell to
 > > a frontend a list of network interfaces he wants available for local
 > > use on his machine (on network, should we have a frontend allowing to
 > > administer a set of machines), and have the frontend present him a
 > > list of matching server and clients.
 > > 
 > > A similar frontend could be used on a server to tell things like "I
 > > want to export a SMTP service (with restriction: not sendmail), but no
 > > TELNET service".  This can make it mostly trivial to get a custom
 > > server up-and-running, especially when combined with debconf to setup
 > > the server config.
 >   Hm.  This sounds to me like an extremely complex task which will be prone to
 > all sorts of 'interesting' complexities and problems.  On the other hand, it
 > might be nice at some point in the future.  And I could be totally wrong :)

I guess this could use the same engine as the mechanism for
file-formats handling, being just another instance of the
language/translator model.

 >   It seems orthogonal to the other classification issue, though

Yes... and maybe no ;)

 > -- 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.

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


Reply to: