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