Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: New category proposal
Date: Wed, 11 May 2005 05:08:57
Message-Id: 20050511050920.GC17034@exodus.wit.org
In Reply to: Re: [gentoo-dev] Re: New category proposal by Georgi Georgiev
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

Replies

Subject Author
[gentoo-dev] Re: Re: New category proposal Duncan <1i5t5.duncan@×××.net>
Re: [gentoo-dev] Re: New category proposal "Kevin F. Quinn" <ml@××××××××.com>