On 22 Aug, 2007, at 5:34, Randall Wood wrote:
Well, no, not really. Its just that I think that they are a really bad way to physically organize the ports collection.
I understand that categories are an important and useful tool for organizing and grouping ports, but when thinking about a GUI for the MacPorts system, I realized that categories should best be thought of as a set of semi-standardized keywords which any mechanism for searching for ports should recognize. I have also been long bugged by the need to decide which category is the primary category for a port when placing it in the ports collection.
I understand the rational for Juan's desire to move the ports tree out of trunk, and would like to suggest that when (if) that happens, that the structure of the ports collection should, at the same time, change from collection/category/port to collection/a/ab/ port, where 'a' is any lowercase alphanumeric character and 'ab' is a combination of any two lowercase alphanumeric characters, and that any port in directory a/ab should start with the characters ab.
I understand that some directories under the proposed scheme may be large, such as /p/p5, /p/py, /g/gn but it seems that this would not be any real change from the current situation for the perl, python, devel, and other directories that exist now.
Personally, I would like to see an "Portdirs" (or some such) file added to ports/, containing a list of dirs to search for for portfiles. The current one would be: aqua/* archivers/* audio/* ... zope/* and yours would be equivalent to: a/*/* b/*/* c/*/* ... z/*/* I think the default should be "*/*" for backwards compatibility, but a Portlist of "*" would provide a prefix-less repository as alluded to later in the thread. What this buys us is: * We can set up deeper hierarchies; there are plenty of python, perl, &c. ports that are basically "a textproc port for python" and these could be in e.g. "python/textproc". * We can exclude, say "groups" and put the PortGroup files there, allowing us to sync the PortGroups with the ports tree. * Users have flexibility to determine their own organization scheme for their personal repositories, including the prefix-less "*". I'm bringing this up because I think it's a more flexible modification; I don't personally see the need to change the port hierarchy to alphabetical organization. A GUI tool can organize the tree however's appropriate, and when I want to cd to a port's directory, `cd */mpd` works fine if I don't remember it's 'audio'. Under your scheme I'd just switch to `cd **/mpd`. Chris