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. As it is, for those who don't use a given package on an everyday basis the categories are extremely obscure. > 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"? ... skip a bit ... > > 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. > > 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. -- \ Georgi Georgiev \ Taxes, n.: Of life's two certainties, the \ / [EMAIL PROTECTED] / only one for which you can get an extension. / \ +81(90)2877-8845 \ \ -- gentoo-dev@gentoo.org mailing list
