Re: Getting rid of section "base" ?
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.
> 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.
* 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.
* I don't really want to have my precious 64Mb RAM wasted by 10
different Xt-derived toolkits.
> Debconf as an example has interface html.
Well, I have to try again to look at how its HTML interface works ;)
> 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 ?
> > 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.
> 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.
Regards,
--
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: