On 2012-03-19, Joshua Root <[email protected]> wrote: > > There is no "default". There are just a bunch of ports. You get > precisely the one you ask for. If you can't decide which one to declare > at the top level, roll dice or something.
This seems then, like there shouldn't be a top-level port when subports are defined. In both cases (multiple versions of PHP, Python, Perl, etc. or a mechanism to group similar ports or those that share the same distfile) common sections are declared at the top-level and the differences are declared within the sub port sections. The top-level should then also be marked as not installable whenever a subport section is present and that top-level port name should not show up in the the index. This solves the issue of user confusion when asking to install "py-foo" and unknowingly also getting "py2x-foo". It also enforces the pattern of depending on py2x-foo instead of py-foo and therefore no warning messages, dummy README files, or behind the scenes dependencies are required. That said, the only advantage of this over picking any one of the grouped ports to be the top-level, is when the top-level port is dropped, but the sub ports are to remain. top: python (non-installable) sub: py24 sub: py25 sub: py26 vs. top: py24 sub: py25 sub: py26 When dropping support for py24, the first can just remove the subport. The second must replace the top-level information that from one of the subports, potentially requiring changes to the other subports as well. The current behavior of the top-level port essentially being a subport that hasn't explicitly been defined as such just seems a bit shifty to me. -- arno s hautala /-| [email protected] pgp b2c9d448 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
