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.
Idea:
* 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:
fileformats/images/png
+- 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 :|
--
Yann.
Reply to: