port command in a stub directory should select the subport automatically if no portname argument

[vinc17@…]

Something is wrong, probably due to the subports:

$ sudo port -v clean --all
--->  Cleaning p5-xml-libxslt
--->  Removing distfiles for p5-xml-libxslt
--->  Removing work directory for p5-xml-libxslt
$ sudo port -v -f destroot
--->  Computing dependencies for p5-xml-libxslt.
--->  Fetching p5-xml-libxslt
--->  Verifying checksum(s) for p5-xml-libxslt
--->  Extracting p5-xml-libxslt
--->  Configuring p5-xml-libxslt
--->  Building p5-xml-libxslt
--->  Staging p5-xml-libxslt into destroot
[...]
$ ls -bF --color -l -go work/**/*(D^/)
-rw-r--r-- 1 201 2011-08-29 01:00:43 work/.macports.p5-xml-libxslt.state
-rw-r--r-- 1  30 2011-08-29 01:00:43 work/destroot/opt/local/share/doc/p5-xml-libxslt/README
$ cat work/.macports.p5-xml-libxslt.state
target: org.macports.fetch
target: org.macports.checksum
target: org.macports.extract
target: org.macports.patch
target: org.macports.configure
target: org.macports.build
target: org.macports.destroot

[blb@…]

That looks right, the p5-* is just a stub since the versioned ports have all the real files.

You probably want something like port destroot subport=p5.12-xml-libxslt (assuming you want the 5.12 version).

[vinc17@…]

I think you missed the point. The goal is that the user can modify the Portfile file (e.g. for testing) and doesn't need to choose the subport. MacPorts should do it for him if the user has typed "port destroot" only. Since building the stub itself is quite useless, one wouldn't lose any feature.

And IMHO, MacPorts should never install a port using the modified Portfile if the user hasn't requested it explicitly. What I mean here is that "port build" in a p5-xml-libxslt directory currently has the effect to install and activate the p5.12-xml-libxslt subport (at least on my machine), which is quite an unexpected behavior (upgrading the other dependencies is OK, as they shouldn't have a modified Portfile).

[jmroot (Joshua Root)]

It's not unexpected that installing p5-xml-libxslt also installs p5.12-xml-libxslt. The former depends on the latter, which is clearly indicated by 'port deps' or 'port info'. The fact that there even is a stub port is a feature of the portgroup, not base, anyway.

[vinc17@…]

This is very poorly designed.

[drkp (Dan Ports)]

Replying to vinc17@…:

I think you missed the point. The goal is that the user can modify the Portfile file (e.g. for testing) and doesn't need to choose the subport. MacPorts should do it for him if the user has typed "port destroot" only. Since building the stub itself is quite useless, one wouldn't lose any feature.

Which subport should it install? Keep in mind that the perl5 ports have four subports besides the main port (stub).

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...)

And IMHO, MacPorts should never install a port using the modified Portfile if the user hasn't requested it explicitly. What I mean here is that "port build" in a p5-xml-libxslt directory currently has the effect to install and activate the p5.12-xml-libxslt subport (at least on my machine), which is quite an unexpected behavior (upgrading the other dependencies is OK, as they shouldn't have a modified Portfile).

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.

[vinc17@…]

Replying to 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).