Re: Getting rid of section "base" ?
On Thu, Dec 02, 1999 at 09:28:47PM +0100, Yann Dirson was heard to say:
> > Hmm. That sounds somewhat reasonable, except that I don't see how it maps
> > to a usable hierarchy -- it seems like you'd get an incredible mess if you
> > tried to represent it. Could you maybe be a little more specific about what
> > you mean? I might just not be understanding your intention..
>
> 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.
> 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)
> > and a new and improved sectioning system wouldn't have to break dselect;
>
> Sure. I don't think any of the proposals presented in this thread
> would break it - it would just go on just using Section and ignore new
> fields. Further more, if as you wrote someone implements proper
> handling of hierarchical sections, the result will still be better
> than it is now !
Ok, I thought maybe you were concerned about this since you pointed out that
dselect won't know about the new sections.
> > 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. Of course, since dselect doesn't let you collapse hierarchies,
this doesn't help much..
> > 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 :)
It seems orthogonal to the other classification issue, though -- 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)
> Disclaimer: this won't in itself teach admin skills to beginners, but
> may still help them to start ;)
Yup.
Daniel
--
Whoever created the human body left in a fairly basic design flaw. It has a
tendency to bend at the knees.
-- Terry Pratchett, _Men at Arms_
Reply to: