Re: Getting rid of section "base" ?
Yann Dirson <ydirson@altern.org> writes:
> Goswin Brederlow writes:
> > 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.
>
> Sure, "gnome" would be sufficient (for now) to derive
> "x11/gtk/gnome". But dropping the first 2 levels would prevent people
> to request eg. "only Gtk apps".
>
> And as for the "3rd level", I don't think we should label it as "3rd"
> - there may be a number of items on the stack - what if someone comes
> with an extension to GNOME, leading to x11/gtk/gnome/foobar ? I'd
> think it would in a first time go into .../gnome/other or
> .../gnome/misc.
>
> Proposal: we could have a skeleton tree including "major" UIs, defined
> by policy, and any new UI/sub-UI is put in <something>/other until it
> becomes necessary to add a new entry.
Sounds good.
> I'm not sure how to avoid potential chaos otherwise.
> > More than 1000 Files in a directory will be a problem. Even more than
> > 100 Files are not the nicest when looking for something.
>
> Yes, but that's an implementation detail - I don't think we should
> care about that. Eg, the pool proposals I saw mentionned splitting
> big dirs using eg. .../em/emacs... which solves the problem.
Which I´m discussing with the proposer at the moment. I don´t like the
alphabetic sorting. Its hard to find something you don´t know the
exact name of.
> > 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.
>
> Maybe. But if we have to find a compromise between these 2 issues,
> I'd rather not give up to much to the "people manually looking through
> the archive" if it impairs the flexibility of the frontends.
>
> In other words, I don't think we want to support "manually using the
> archive" as much as "using frontends".
Any frontend can just ignore the archive structure and use the info
from the packages files alone. I think that even if the nature is
encoded onto the archive via the directory structure, that info should
still not be erased from the packages file, so the archive structure
doesn´t offer more information than the packages files (or the control
files of a package), but helps people finding their way through the
archive.
May the Source be with you.
Goswin
Reply to: