#31009: port command in a stub directory should select the subport automatically if no portname argument ----------------------------------+----------------------------------------- Reporter: vinc17@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: base | Version: 2.0.1 Resolution: invalid | Keywords: Port: | ----------------------------------+----------------------------------------- Comment(by vinc17@…): Replying to [comment:7 dports@…]:
Which subport should it install?
The ideal would be that a stub should behave as an alias of some context- dependent port (i.e. instead of having a dependency relation, one would have an alias relation). Even without that, the case of "port" being executed in a port directory without a portname as argument should be fixed. When I run "port info p5-xml-libxslt", I get: {{{ p5-xml-libxslt @1.700.0, Revision 3 (perl, textproc) Replaced by: p5.12-xml-libxslt [...] }}} So, I would say that when running "port build", instead of building p5 -xml-libxslt (with the effect of installing its dependencies, including p5.12-xml-libxslt), it should build p5.12-xml-libxslt directly (thus without installing it). A user who wishes to select another subport could do this with additional arguments, like when selecting variants. I'm not sure that looking at "Replaced by:" is sufficient. In doubt, when building a port would lead to the installation of a subport, this should return an error instead of installing it.
And although currently the only ports using subports are the perl5/python ports, where the main port is just a stub that depends on one of the subports, that isn't necessarily true in general. (Consider the subports I proposed in #31027, for example...)
I think this example is nice. Typing "port build" in the gwenhywfar4 directory won't install gwenhywfar4-gtk. There's probably nothing special to do with it.
Actually, it'll install whatever p5.12-xml-libxslt is in your ports tree, not specifically the one from the portfile in your current directory. I'm not sure whether you'd consider that better or worse, but at least it's consistent with all other dependencies.
This can be even more confusing. IMHO, dependencies on a subport should be forbidden and replaced by another concept (perhaps the "Replaced by" + dependency can be a way to express this concept). -- Ticket URL: <https://trac.macports.org/ticket/31009#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS