On Aug 22, 2007, at 07:13, Daniel J. Luke wrote:
On Aug 22, 2007, at 5:34 AM, 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.
why?
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.
there's nothing that forces the gui to adopt a display that mirrors the physical (on disk) layout of the ports.
The current categories are there so that humans can browse the ports directory and see related ports somewhat grouped together.
Indeed. Why complicate things with weird sub-directories? If you really don't want an on-disk port heirarchy (understandable), then we could just stick them all in one directory. It's a flat namespace, after all. Honestly, though, this sounds like more change for the sake of change. Is there a technical advantage to changing the implementation? -landonf