1 |
> On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote: |
2 |
> Here's my suggestion, for what it's worth :) |
3 |
> |
4 |
> The layout on disk and the semantics of categories do not need to be related. |
5 |
Yes and no. You're assuming that people don't use the layout on disk for digging |
6 |
around without calling portage. Personally, I do. |
7 |
|
8 |
> I like the idea of using the first character of a package name as the |
9 |
> sub-directory name. This can be extended more deeply as and when necessary to |
10 |
> avoid over-large directories which cause problems on some filesystems. e.g. |
11 |
> for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is |
12 |
> architecture-neutral, rsyncable, scalable, and not too difficult for users to |
13 |
> parse manually (see later for searching through categories). If the algorithm |
14 |
> portage would use to locate a package is such that it doesn't mandate the depth |
15 |
> (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if "p/a/" |
16 |
> exists) then overlays can have a different depth to the rsync tree; if you only |
17 |
> have a few packages in overlay then they need not be in subdirectories at all. |
18 |
Re-asserting that the fs layout *does* matter, how is that more intuitive when trying |
19 |
to track down the ebuild for dev-util/diffball ? How many directories deep would I have |
20 |
to go before I reached the ebuild? |
21 |
|
22 |
The changes I posit aren't anymore friendly to devs doing ebuild work, and requires |
23 |
a flat namespace- no conflicts, meaning that we have to choose alternate names for conflicts |
24 |
(or the category data winds up in the name). Like I said, I really dislike debian's flat |
25 |
namespace, even if we had a category component to it. |
26 |
|
27 |
> The key here is to separate the category (metadata) and filesystem layout |
28 |
> (implementation detail) from the concept of package name. This opens up all |
29 |
> sorts of possibilities, for example different layouts in CVS, on mirrors and on |
30 |
> clients (some kind of custom rsync would be necessary) - but that's going |
31 |
> perhaps too far... |
32 |
This also locks out several possibilities, like relying on dir structure to limit the searches. |
33 |
You force category classification to be metadata, you need an additional db to do searching, |
34 |
and basic atom lookup. That's 19000+ keys in a db. No db, and you force a tree |
35 |
wide search, which _will_ be as fast as emerge -S is. |
36 |
|
37 |
> Categories become metadata, formally (this is the root of the problem - |
38 |
> including the category in the package name is a pollution of the package name). |
39 |
> Once they become properly understood and implemented as metadata, a package |
40 |
> being a member of more than one category is a natural consequence. |
41 |
Currently, the only conflicts that can occur in searches are package specific. Atoms, |
42 |
the basis of our depends system require categories; as such conflicts *cannot* occur. |
43 |
Multiple categories per package allows for conflicts to occur in our deps. This is |
44 |
nasty, and again, requires pretty much a walk of the whole tree to verify no conflicts |
45 |
(mr_bones_, aka michael sterret would probably quietly curl up and die when his repoman runs, |
46 |
which are now under an hour, clear 2 hours again) :) |
47 |
|
48 |
> Portage would essentially ignore categories. Some support would be necessary |
49 |
> to allow the user to query categories (since 'ls /usr/portage/<category>' would |
50 |
> no longer work) - but searching for packages is already a function and would |
51 |
> just need to be adapted (and perhaps optimised ;) ). Indeed just listing out |
52 |
> portage directories at the moment is often insufficient to find a suitable |
53 |
> package, since package names are often amusing but uninformative acronyms. |
54 |
Portage can't ignore categories, see the bit above about cat/pkg-ver (cpv from this point |
55 |
on) conflicts. cpvs can't conflict, pure and simple under the current layout, which is |
56 |
enforce by the single category/fs layout. |
57 |
|
58 |
What are we gaining? Ability to find a package under two categories? |
59 |
|
60 |
|
61 |
> The benefits include |
62 |
> 1) no more "moving packages around the tree" |
63 |
cpv conflict. You aren't moving the fs position of it, but it still requires |
64 |
walking the tree and updating all atom's that reference the old position. |
65 |
|
66 |
> 2) categories can be added to a package in the most natural way |
67 |
Elaborate. |
68 |
|
69 |
> 3) overlays can be tidier |
70 |
Eh? |
71 |
|
72 |
> well, it's a big downside... |
73 |
E'yep. :) |
74 |
|
75 |
> Having said that, some things could be done now. If a flat package namespace |
76 |
> is desirable, the existing package name clashes could be resolved by renaming |
77 |
> the few packages that clash. |
78 |
74 packages, roughly, out of 9429 roughly. |
79 |
|
80 |
> Category could be added as a field in |
81 |
> metadata.xml, so that a package could "belong" to multiple categories. |
82 |
> The query/search tools could be enhanced to scan this metadata (perhaps including |
83 |
> the current category directory as an implied entry in the metadata.xml). |
84 |
If that's the goal of the "belong to N categories" thread, strictly searching, |
85 |
sure, although I don't like it. It can't become an atom for *DEPEND due to the cpv |
86 |
nonconflicting bit. |
87 |
~brian |
88 |
-- |
89 |
gentoo-dev@g.o mailing list |