Re: Getting rid of section "base" ?
Daniel Burrows writes:
> > > -> File Formats, a listing of all file formats the program can manipulate,
> > > possibly restricted to some common ones and catch-alls,
> >
> > This could be investigated using the "language/translator" model I
> > succintly depicted in Message-ID: <[🔎] 14405.39784.502704.61623@bylbo.nowhere.earth>
> > (same subject, same date, reply to Goswin).
>
> 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).
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 ?
> 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 !
> 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 :).
> > > Personally, I would like to see the "Nature" tag split between libraries,
> > > programs, data, and documentation, the "Interface" tag split
> > > between X, console, tty, and daemon (ie, no meaningful UI), and some more tags:
> >
> > About "daemon" interface, I'd rather classify a daemon as "Nature:
> > server; ClientInterface: whatever-if-useful". I see 2 orthogonal
> > issues here.
>
> 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.
Disclaimer: this won't in itself teach admin skills to beginners, but
may still help them to start ;)
--
Yann Dirson <ydirson@altern.org> | Why make M$-Bill richer & richer ?
debian-email: <dirson@debian.org> | Support Debian GNU/Linux:
| Cheaper, more Powerful, more Stable !
http://www.altern.org/ydirson/ | Check <http://www.debian.org/>
Reply to: