| 1 |
On Wednesday 04 June 2003 16:23, Rolf Veen wrote: |
| 2 |
> George Shapovalov wrote: |
| 3 |
> > Ok, this seems to be pretty much it, at least from what I remember |
| 4 |
> > being mentioned on this topic. Again, if anybody thinks I ommitted |
| 5 |
> > something, please stand up and mention it :). |
| 6 |
> |
| 7 |
> Namespace orthogonal to categories. |
| 8 |
> |
| 9 |
> Categories change, as packages are being added; if a category has more |
| 10 |
> that N (lets say 50, for example) entries it looses its usefullness. |
| 11 |
> While browsing for packages it is natural to have some level of depth; |
| 12 |
> two or tree levels of categories should be ok. Also a package can fit |
| 13 |
> into more that one category. Let categories be a graph. A symlink |
| 14 |
> hierarchy, for example. |
| 15 |
|
| 16 |
Unfortunately CVS does not work well with symlinks, so this is not really an |
| 17 |
option. Also there is an advantage in being able to have one unique name for |
| 18 |
a package. |
| 19 |
|
| 20 |
> |
| 21 |
> But since categories are variable and somewhat arbitrary, don't let |
| 22 |
> the basic system, the core algorithms, depend on them. So take a flat |
| 23 |
> namespace for packages, resolving name conficts in the download (url |
| 24 |
> to local dir) phase, adding the necesary information to the ebuild. |
| 25 |
|
| 26 |
We need unique names. For me category/name is a good way, and certainly better |
| 27 |
than UID's (Like microsoft uses) as those are impossible to remember and easy |
| 28 |
to do wrong. Also we have a central repository, so we don't need to worry |
| 29 |
about clashes that much. |
| 30 |
|
| 31 |
> |
| 32 |
> Concluding, have a flat namespace for machine interaction, and an |
| 33 |
> arbitrarily complicated category graph on top of that for user |
| 34 |
> interaction. |
| 35 |
|
| 36 |
Flat namespaces are actually slower in machine interaction. There are allready |
| 37 |
very many packages in portage currently. Thousands of entries in a directory |
| 38 |
is NOT fun to look at, or to search for a computer (albeight doable). |
| 39 |
|
| 40 |
My suggestion would be an alias list simmilar to the virtuals list, but one |
| 41 |
that is not allowed inside ebuilds. In those ways packages can still be |
| 42 |
presented in multiple categories, while the aliasses do not interfere with |
| 43 |
the inner workings of portage. |
| 44 |
|
| 45 |
Paul |
| 46 |
|
| 47 |
-- |
| 48 |
Paul de Vrieze |
| 49 |
Researcher |
| 50 |
Mail: pauldv@××××××.nl |
| 51 |
Homepage: http://www.devrieze.net |
Archives