handle only subports install files

[Arno Hautala]

On 2012-03-19, Joshua Root <jmr at macports.org> 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    /-|   arno at alum.wpi.edu

pgp b2c9d448