Re: Getting rid of section "base" ?
Yann Dirson <ydirson@altern.org> writes:
> Goswin Brederlow writes:
> > > > Interface: tty (stdio, dialog), X11 (Xt, Qt)
> > >
> > > Problem I see: we can't sub-classify Xaw and Motif from Xt with such a
> > > syntax.
> >
> > Interface: X11 (Xt (Xaw))
> [...]
> > A Syntax with brackets would save repeating the front part as e.g. in
> > X11/X1/Xaw + X11/Xt/Motif.
>
> I understand your point. But that could also be expressed as
> regexp-like expressions: X11/Xt/(Xaw|Motif) or X11/Xt/(!Motif)
> would be potentially useful examples.
As you wish.
> > I sugest that anything might be set as
> > interface for the subtypes but not for the first or first two levels,
> > which should be defined and exhaustive. Hardly anybody cares what
> > subtype of Xt is used by a program, but if the maintainer cares, he
> > can mention it.
>
> Hm, I don't agree with several issues here:
>
> * As a user I'd expect that a query for, say, "games using GNOME" do
> not only give me 10% of them. That would IMHO really lower the
> usefulness of the thing.
Of cause main guis should be mentioned, but something like gnome woult
be x11/gnome and the first two level would be exactly spezified and
relevant. But the third level specifying what subtype of a gui is used
is probably irrelevant to the user and could be optional or left to
the maintainer (of the gui) to specify.
For example tcl/tk should have its versions as subtypes, since they
are mostly incompatible. A Package stating that it runs on Interface
tcl/tk without version subtype could mean all version.
> * I'd rather suggest that maintainers of a new GUI package gets its
> GUI registered in an official list if necessary. Not centralizing
> such strings may cause several concurent strings to be use (say, "fb"
> vs "fbdev" vs "framebuffer"), and would again lower the usefulness of
> the thing. I tend to compare such a list to the "menu" hierarchy,
> which is defined by policy.
The menu hierarchy is a good analogon and the same algorithms should
be used to make a nice structured menu in a frontend.
> * I don't really want to have my precious 64Mb RAM wasted by 10
> different Xt-derived toolkits.
What do you mean with that? Don´t install them. The depends would also
tell you that a package needs some special gui.
>...
> > A major thing is fb, whereas X11 may be a subset of fb as can be
> > berlin or ggi. I don´t now if there are any pure fb prorams except the
> > XServer and the ggi fb traget, but might be worth keeping in mind.
>
> I'm not sure what you're suggesting here... fb/X11 ? That one would
> erroneous, and would caracterize a superset, not a subset (as Xt is a
> superset of X11), which would not be true as well.
>
> Could you please explain your point further ?
Most graphics interfaces work on a Framebuffer with the exception of
svgalib. Also ggi runs on fb, svgalib, aalib,... Some Interfaces are
hard to specify or could be links. I think the help texts given for
the gui selection in frontends should point out that certain programs
will be under different interfaces but will still work on this
interface via a target library (e.g. ggi will say that all X programms
can be run in the ggi X-server or the fb will tell that you can use
X11 or ggi stuff).
> > > In my mind "games" is still a section - eg. you'll find clanlib as
> > > "Nature: lib; Section: games".
> >
> > Yes, your right. Still there are so many programs in debian and
> > looking for some special game of which you don´t exactly know the name
> > will be hard and also the filesystem overhead will be great for a
> > large directory.
>
> Then what you need is probably more an advanced "find" capability in
> dselect/gnome-apt/whatever, and I don't think filesystem organization
> is relevant at this level.
More than 1000 Files in a directory will be a problem. Even more than
100 Files are not the nicest when looking for something.
> > X11 would be under "server"? At least most of it I would guess. Or
> > should there be a directory for guis?
>
> These are ortogonal issues - we could have:
>
> Nature: server
> Section: x11 or ui/x11
>
>
> > Nature as in "Server" "Lib" "Doc" ... I would like those to show up in
> > the archives structure to shrink directory sizes.
>
> There may be a problem in attempting to use such orthogonal
> hierarchies on a storage which only natively support one.
>
> Anyway archive structure only has to be understandable by the
> frontends, and easily mirrorable, isn't it ? I think archive
> structuring is an orthogonal issue.
Some structure is needed on the archive and the nature seems in my
eyes be the most usefull to people looking through the archive without
the frontend.
May the Source be with you.
Goswin
Reply to: