On Wed, May 11, 2005 at 01:27:46PM +0900, Georgi Georgiev wrote: > As to whether the categories are good or not... think about it. If they > were good, would we still be seeing packages moving around the tree? > That's why I think that multiple categories are a necessity. Unless of > course, packages stop getting moved around and Gentoo can gurantee that > all packages will stay at their current location.
Keep in mind the tree is in constant flux, new packages added, packages removed, etc. Of course there will be a bit of reorganization, unless we add every possible category under the sun (even then, $10 on some weird esoteric category being requested shortly after such a change) ;) Point I'm getting at is that the need for a better groupping occurs depending on the packages being added. One thing that just clicked in the skull on why flat-tree has issues; currently it's possible to have a package with the same name, yet a differing category (app-vim/sudo vs app-admin/sudo). Since our tree layout is based upon category, if you tried shifting the focus of it to packages_in anyway_, you would explicitly disallow same name packages, different category. Doesn't matter how you structure the tree, if you do lookup into the tree based on package, not category, you disallow same named packages. > What about the Mozilla suite. What in the world is it doing in > www-client? After all, the Mozilla suite is > - a www browser (www-client) > - a mail client (mail-client) > - a calendar > - an html composer > - an irc client (net-irc) > > Might as well go to net-misc :-/ This is why I commented that there are exceptions, question is if the exceptions are annoying enough the level of change required, is implemented (I posit no, but that's cause I see issues w/ the resulting namespace, and am lazy). > - I hate the moves of packages between categories which causes enough > problems as it is. I also find the arguments of where to put what > pointless. Who cares if it is mail-client/mutt or net-mail/mutt as > long as it stays in one place and is accessible by its name "mutt". If > you think that mail-client is more descriptive than net-mail, The category labelling of it matters for those who go groking for an app to use, but don't know the possibilities. Example: "well, lets see what mail clients exist, and pick one of 'em for use based upon the description, since I've had it with my current mail client"... > then add > "keywords" (for those who hate the idea of multiple categories) to the > metadata of each package and let emerge -s search by keyword. Does > "mutt" not belong to net-mail? It does, but mail-client is better. > Still, that is no reason to remove its relation to "net-mail". Cache > the keyword information to make the search as fast as possible and > you're done with the searchability part. You can now safely forget > about this thing called "categories" as they become irrelevant, and > hopefully never move another package. > - I also hate being unable to find exactly the package that I need right > away. I want to check mutt's ebuild... cd /usr/portage/... what next? > Is it at the same place that I remember it was the last time I > checked? Do I *have* to know what category it belongs to? Of course I > can do "cd /usr/portage/*/mutt", but shell completion on the mutt part > won't work on this one. Mutt's not quite the example for the necessity > of completions, but it gets worse with longer names like > mozilla-firefox-bin. Re: yeah, it's fricking annoying, agreed. I'd state a faster tool is preferable, rather then a reorganization (imo). See above about why flattening the tree so it's package-centric rather then category-centric has issues. The consequence is that you have to start moving category specific metadata into the package name when valid conflicts occur- the sudo/vim example above, would require vim-sudo or vim-plugins-sudo. Debian does this, they (ab|)use a flattened namespace. I strongly dislike it, even compared to the consequences of our N category approach. Granted they lack (afaik) category data, but the consequences of flattening the namespace still stands imo. :) So... next possibility is doing the additional categories via extra metadata (xyz is *primarily* cat a, but also is cat b and c). Complaints over speed would easily triple if this was added; if you don't find a package within a (on disk dir) categories namespace, you have to walk the metadata for *all* ebuilds to verify that there isn't another package that has allegance to that category. Yes, this can be cached, but it is a pita and is added complexity (in other words, gains needs to offset this extra cost). > - Personal overlays. I think this a point that's clear enough. Gentoo > devs may have scripts that keep the tree in sync after the > loved-by-all move of a package, but that doesn't apply to us, mere > mortals. Got me there. Would need an active translation layer, cpv was this, is now that, to make overlays a bit friendlier. Note I'm commenting on -overlays-, not -repositories- (bmg's stuff is effectively a repository). Translation bit might apply there also, but that's getting into a terminology discussion... :) > Disclaimer: I did not intend to be offensive even if at times I seem to. > I was not being sarcastic either. Sarcasm goes with the territory, wouldn't worry- you're making your points, not relying on sarcasm/offense to be your points. The former just adds to the fun. ;) ~Brian -- gentoo-dev@gentoo.org mailing list
