On Wed, May 11, 2005 at 11:11:02AM -0400, Alec Warner wrote: > >>>Yes and no. You're assuming that people don't use the layout on disk for > >>>digging > >>>around without calling portage. Personally, I do. > Not need to be related, but shouldn't be related. In essence this > allows people to put the tree where-ever, as long as that storage > mechanism supports the database operations required ( stuffing > everything in a SQL db fex ). I don't know why someone would....but hey ;)
Not a valid arguement for dropping categories however, since I'm playing with sqlite based repository module atm locally :) (don't ask for it, it's not even remotely ready for any use beyond destroying things locally on my box at the moment) Category is just a bit of info used for looking up a node (category="xyz" and package="abc"). Shouldn't isn't applicable here; in this case, category *is* required due to our atoms, unless people manage to push flattening the namespace through. :) > >>The fact that the directory where diffball is is easily deducable by its > >>name. As it is, I'd be a bit lost if I had to guess whether diffball is > >>in app-arch or dev-util. Even if I remembered it was something > >>dev-related I'd still be inclined to look in sys-devel. > > > > dev-util is accurate (it's a compressor, but a specialized variant, > > same as patch is). From it's current fs location/layout, we get thus- > > quick lookup on the atom, and inference of it's intentions. This is > > why we have xml at the category level, for example. > > > > One thing that's being unstated also- it's implicitly stated that this > > directory structure is somehow easier to look up a package. If you > > know the _exact_ package name, maybe. Otherwise, you're falling back > > to a search tool (which defeats to some degree the whole arguement for > > flattened namespace). > > Some quicky python, grouping by first char of the package name, and > > you wind up with (top 8)- > > 421, 521, 571, 582, 657, 663, 664, 746 > Assuming the directories are ordered by letter, ( a,b,c,d ) and > subdirectories if present as well, a bsearch wouldn't be bad. Both are > ordered sets and you can quickly determine the location of a package in > log(n) time. I don't see a big deal here. Dodging my point though. I was pointing out that the categories approach decreases the number of directories/packages within each grouping, while first letter approach jacks up the # of dirs w/in dirs (in some cases, of course). basically, a category fs layout is easier on the human who is digging in if they don't know what they're exactly hunting for, point still stands. :) Regarding bsearch, ehh. listdir returns a list (not an iterable over the (open|read|close)dir syscall), so you'd have to either resort to a linear search, or sort then bsearch it. Like I said, the issue isn't how we code things to make it speedy, my concern outlined above is purely the human factor in dealing with the proposed tree structure. > > I know the path as sys-apps/portage already though. Doesn't that > > count for something? :) > > > > Or, a bit more likely case, I know the type of the package, the > > category, but don't recall it's exact name. What y'all are proposing > > forces the user to use a tool, rather then just a quicky ls. > > *tongue in cheek* and what is ls but another tool for listing the > contents of a directory :) ls does no good if you're trying to see all packages of a category, under this proposal, which is what I'm driving at. It forces the user to use scripts/tools to do querying. > >>I personally want to see the category part *disappear* from the *DEPEND > >>which is one of the reasons to advocate a flat tree. If the category (or > >>part of it) goes in the package name, so be it, but at least there will > >>be no package moves to break older ebuilds or outdated overlays. > > > > Frankly, you need to give a *really* damn good reason for why this is > > better. I don't think it is, convince me otherwise. > > > > What do we gain from a flat namespace? > > Right now, I can infer an atom out of a DEPEND string's purpose to > > some degree, based upon it's category. To head off the "well you > > don't need to know the category, you should know the packages > > intentions if you're modifying the ebuild", that dodges the point; via > > the category portion of an atom, I can infer at least -intention- of a > > package. > > The CPV thing.....is a big fix :( > > > Ignoring changes required (have stated them already, no point in > > sniping ya over it), what _exactly_ do we gain from the change? So... what do we gain? Like I said, ignore for a second that massive overhaul required; if work is required to gain something, and what's gained is worth it over the work, sure. I'm not seeing the gain though :) The original request was having a package turn up in multiple categories for searching, right? I don't like it, but metadata.xml at the package level could probably be extended for that, *strictly* for searching. It cannot, *ever* be used for satisfying an atom imo. Reason being it allows for the cpv conflict, rather then just package conflicts we have now. ~Brian -- gentoo-dev@gentoo.org mailing list
