Re: [gentoo-dev] Re: New category proposal

[Brian Harring]

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@g.o mailing list