1 |
On Wed, May 11, 2005 at 01:27:46PM +0900, Georgi Georgiev wrote: |
2 |
> As to whether the categories are good or not... think about it. If they |
3 |
> were good, would we still be seeing packages moving around the tree? |
4 |
> That's why I think that multiple categories are a necessity. Unless of |
5 |
> course, packages stop getting moved around and Gentoo can gurantee that |
6 |
> all packages will stay at their current location. |
7 |
|
8 |
Keep in mind the tree is in constant flux, new packages added, |
9 |
packages removed, etc. Of course there will be a bit of |
10 |
reorganization, unless we add every possible category under the sun |
11 |
(even then, $10 on some weird esoteric category being requested |
12 |
shortly after such a change) ;) |
13 |
Point I'm getting at is that the need for a better groupping occurs |
14 |
depending on the packages being added. |
15 |
|
16 |
One thing that just clicked in the skull on why flat-tree has issues; |
17 |
currently it's possible to have a package with the same name, yet a |
18 |
differing category (app-vim/sudo vs app-admin/sudo). |
19 |
|
20 |
Since our tree layout is based upon category, if you tried shifting |
21 |
the focus of it to packages_in anyway_, you would explicitly disallow |
22 |
same name packages, different category. Doesn't matter how you |
23 |
structure the tree, if you do lookup into the tree based on package, |
24 |
not category, you disallow same named packages. |
25 |
|
26 |
|
27 |
> What about the Mozilla suite. What in the world is it doing in |
28 |
> www-client? After all, the Mozilla suite is |
29 |
> - a www browser (www-client) |
30 |
> - a mail client (mail-client) |
31 |
> - a calendar |
32 |
> - an html composer |
33 |
> - an irc client (net-irc) |
34 |
> |
35 |
> Might as well go to net-misc :-/ |
36 |
|
37 |
This is why I commented that there are exceptions, question is if the |
38 |
exceptions are annoying enough the level of change required, is |
39 |
implemented (I posit no, but that's cause I see issues w/ the |
40 |
resulting namespace, and am lazy). |
41 |
|
42 |
|
43 |
> - I hate the moves of packages between categories which causes enough |
44 |
> problems as it is. I also find the arguments of where to put what |
45 |
> pointless. Who cares if it is mail-client/mutt or net-mail/mutt as |
46 |
> long as it stays in one place and is accessible by its name "mutt". If |
47 |
> you think that mail-client is more descriptive than net-mail, |
48 |
The category labelling of it matters for those who go groking for an |
49 |
app to use, but don't know the possibilities. Example: "well, lets |
50 |
see what mail clients exist, and pick one of 'em for use based upon |
51 |
the description, since I've had it with my current mail client"... |
52 |
|
53 |
|
54 |
> then add |
55 |
> "keywords" (for those who hate the idea of multiple categories) to the |
56 |
> metadata of each package and let emerge -s search by keyword. Does |
57 |
> "mutt" not belong to net-mail? It does, but mail-client is better. |
58 |
> Still, that is no reason to remove its relation to "net-mail". Cache |
59 |
> the keyword information to make the search as fast as possible and |
60 |
> you're done with the searchability part. You can now safely forget |
61 |
> about this thing called "categories" as they become irrelevant, and |
62 |
> hopefully never move another package. |
63 |
> - I also hate being unable to find exactly the package that I need right |
64 |
> away. I want to check mutt's ebuild... cd /usr/portage/... what next? |
65 |
> Is it at the same place that I remember it was the last time I |
66 |
> checked? Do I *have* to know what category it belongs to? Of course I |
67 |
> can do "cd /usr/portage/*/mutt", but shell completion on the mutt part |
68 |
> won't work on this one. Mutt's not quite the example for the necessity |
69 |
> of completions, but it gets worse with longer names like |
70 |
> mozilla-firefox-bin. |
71 |
|
72 |
Re: yeah, it's fricking annoying, agreed. I'd state a faster tool is preferable, |
73 |
rather then a reorganization (imo). |
74 |
|
75 |
See above about why flattening the tree so it's package-centric rather |
76 |
then category-centric has issues. The consequence is that you |
77 |
have to start moving category specific metadata into the package |
78 |
name when valid conflicts occur- the sudo/vim example above, would |
79 |
require vim-sudo or vim-plugins-sudo. |
80 |
|
81 |
Debian does this, they (ab|)use a flattened namespace. I strongly |
82 |
dislike it, even compared to the consequences of our N category |
83 |
approach. Granted they lack (afaik) category data, but the |
84 |
consequences of flattening the namespace still stands imo. :) |
85 |
|
86 |
So... next possibility is doing the additional categories via |
87 |
extra metadata (xyz is *primarily* cat a, but also is cat b and c). |
88 |
Complaints over speed would easily triple if this was added; if you |
89 |
don't find a package within a (on disk dir) categories namespace, you |
90 |
have to walk the metadata for *all* ebuilds to verify that there isn't |
91 |
another package that has allegance to that category. Yes, this can be |
92 |
cached, but it is a pita and is added complexity (in other words, |
93 |
gains needs to offset this extra cost). |
94 |
|
95 |
> - Personal overlays. I think this a point that's clear enough. Gentoo |
96 |
> devs may have scripts that keep the tree in sync after the |
97 |
> loved-by-all move of a package, but that doesn't apply to us, mere |
98 |
> mortals. |
99 |
|
100 |
Got me there. Would need an active translation layer, cpv was this, |
101 |
is now that, to make overlays a bit friendlier. |
102 |
|
103 |
Note I'm commenting on -overlays-, not -repositories- (bmg's stuff is |
104 |
effectively a repository). Translation bit might apply there also, |
105 |
but that's getting into a terminology discussion... :) |
106 |
|
107 |
> Disclaimer: I did not intend to be offensive even if at times I seem to. |
108 |
> I was not being sarcastic either. |
109 |
|
110 |
Sarcasm goes with the territory, wouldn't worry- you're making your |
111 |
points, not relying on sarcasm/offense to be your points. |
112 |
The former just adds to the fun. ;) |
113 |
~Brian |
114 |
|
115 |
-- |
116 |
gentoo-dev@g.o mailing list |