On Wed, May 11, 2005 at 06:01:17PM +0900, Georgi Georgiev wrote: > maillog: 11/05/2005-03:40:04(-0500): Brian Harring types > > > On Wed, May 11, 2005 at 09:46:03AM +0200, Kevin F. Quinn wrote: > > > Here's my suggestion, for what it's worth :) > > > > > > The layout on disk and the semantics of categories do not need to be > > > related. > > Yes and no. You're assuming that people don't use the layout on disk for > > digging > > around without calling portage. Personally, I do. > > > > > I like the idea of using the first character of a package name as the > > > sub-directory name. This can be extended more deeply as and when > > > necessary to > > > avoid over-large directories which cause problems on some filesystems. > > > e.g. > > > for sudo you get "s/sudo" and vim-sudo "v/vim-sudo". This is > > > architecture-neutral, rsyncable, scalable, and not too difficult for > > > users to > > > parse manually (see later for searching through categories). If the > > > algorithm > > > portage would use to locate a package is such that it doesn't mandate the > > > depth > > > (i.e. tries "package", "p/package" if "p/" exists, "p/a/package" if > > > "p/a/" > > > exists) then overlays can have a different depth to the rsync tree; if > > > you only > > > have a few packages in overlay then they need not be in subdirectories at > > > all. > > Re-asserting that the fs layout *does* matter, how is that more intuitive > > when trying > > to track down the ebuild for dev-util/diffball ? > > > 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 Seperate directories within an individual directory. Say 'd' for example, and we'll pretend 746 is the count of packages that start with 'd'. That's a butload of directories to go digging in. The response would be, "well then extend it to the first two chars after the first dir". You narrow it down, but add another layer of dirs, again, for what gain? See, the thing I find odd about this thread/request is that essentially breaking it down to first letter groupping, is being argued as being _easier_ for people, while allowing multi cats, or just flat out dropping the category aspect. The example above, imo, proves otherwise. Keep in mind at this point, the discussion is whats easiest for _humans_. What's easiest for code/comp is another matter, and (within limits) can work with anything that's thrown at it. > > How many directories deep would I have to go before I reached the > > ebuild? > > Does it matter? You know the path exactly. It's p/portage. It's > not ... "was it sys-apps/portage or app-portage/portage"? 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. > > > Having said that, some things could be done now. If a flat package > > > namespace > > > is desirable, the existing package name clashes could be resolved by > > > renaming > > > the few packages that clash. > > 74 packages, roughly, out of 9429 roughly. > > 76/9295, which is not that bad, considering about half of them are > emacs/xemacs related. 'cept either you, or someone else was proposing a totally flat namespace, no cats in the atoms. That means the count of changes (the 76 above is just # of conflicting packages) is around 19000, plus a fairly large amount of portage modifications. > > > Category could be added as a field in > > > metadata.xml, so that a package could "belong" to multiple categories. > > > The query/search tools could be enhanced to scan this metadata (perhaps > > > including > > > the current category directory as an implied entry in the metadata.xml). > > If that's the goal of the "belong to N categories" thread, strictly > > searching, > > sure, although I don't like it. It can't become an atom for *DEPEND due to > > the cpv > > nonconflicting bit. > > 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. Ignoring changes required (have stated them already, no point in sniping ya over it), what _exactly_ do we gain from the change? ~brian -- gentoo-dev@gentoo.org mailing list
