The stub PG should (be able to) clear all pre- and post- blocks

[RJVB (René Bertin)]

Anyone who has ever had to deal with the situation where a port is (or has to be) nothing but a stub knows that it can get unnecessarily complicated to implement. The stub PG helps but not with the fact that pre-X and post-X code blocks will be executed anyway.

I don't really know what's the ideal solution here, clearing all those pre- and post- blocks from the stub PortGroup or simply not executing them under specific condition(s). The stub PG currently uses a post-destroot block itself but that could just as well be used as the destroot instead.

[ryandesign (Ryan Carsten Schmidt)]

MacPorts base has no such ability and I'm not convinced adding that ability is useful. It's not hard to structure a port correctly so that pre- and post- blocks are only created for those subports that are not stub ports.

[RJVB (René Bertin)]

Maybe not hard but it doesn't help readability, esp. if there are multiple blocks to be protected this way. My own approach is often to put the stub subport as close to the top as possible, with a return to shunt parsing of the rest of the Portfile, but that has other potential side-effects.

Implementation-wise it seems easiest to skip the invocation of the corresponding code if e.g. stub::setup_stub is defined (implies considering the stub PG as part of "base" I suppose). I'm adopting that for now in my Linux adaptation (where I can't get around the fact that certain packages/ports are best taken from the host and I want to see how far I can get with central +fromHost variant that turns the port into a shim, rather than making custom ports that don't declare the dependencies in question).

But if one takes the position that "base" implements a dedicated language (I tend to think of it that way) then it feels like a lacking feature that build {}, destroot {} etc. allow to skip those stages but there is no way to skip the associated pre- or post- stages. At the very least there could be use_pre_??? options like there is a use_configure option (does that one disable the pre-configure and post-configure blocks in fact?), or a single option to "skip pre- and post- for empty build stages. Sticking with the 2 examples: build no or destroot no could also be an elegant way to achieve selective skipping of the entire phase.

[ryandesign (Ryan Carsten Schmidt)]

use_configure no disables the configure phase. It does not disable any pre-configure or post-configure blocks that might exist, and I'm sure you can find countless examples of ports that rely on that fact. We've made it 22 years without needing a way to disable pre- and post- blocks so I am confident you can code your hypothetical portfiles in a way that does not require this new feature.

[mascguy (Christopher Nielsen)]

As the author of this portgroup, I can speak to the goal:

It is intended for skeleton ports, where no behaviors have been defined. As opposed to trying to wipe out any and all behaviors of a port after-the-fact, which sounds like what you're looking for...?

[RJVB (René Bertin)]

But it does "wipe out behaviours after-the-fact", only not all.

I'm not saying one cannot do without, only that it would be more elegant. Well, and if the PG is meant to create only skeleton ports (whatever those are) then I suppose I'd argue that it isn't named properly. It seems to provide a mechanism to turn a (sub)port into a stub and from what I've seen that's what it's also being used for.

The "we've done XX years without" can be used to argue against any evolution, like the one of vercmp a while back, which was just as unnecessary and justifiable as what I'm proposing here. IMHO, YMMV and all that of course.

Meanwhile I've given a few suggestions and rolled my own solution for my Linux implementation so I've said what I had to say. Unless there's a genuine interest to look into this constructively, of course.

[ryandesign (Ryan Carsten Schmidt)]

Maybe you can provide an example portfile that demonstrates where the existing method would be particularly inconvenient.

[RJVB (René Bertin)]

I'll see if I can remember where, but I discovered the stub PG only relatively recently so such examples can be well hidden, so to speak.

I don't really see a use for the underlying idea that I'm working on, where a generic variant (not unlike the +universal variant) has to turn a port into a stub, but that would be the perfect example otherwise. I don't have to explain how complicated tuning individual ports to universal builds can become, and there it's undoubtedly inevitable. But if somehow it weren't, wouldn't you consider that having to tweak individual ports defeats the purpose of a generic variant at least somewhat?

The closest thing to that what I'm currently working on is probable the design used in a large number of the python ports I've seen, where the main port (py-foo) is a stub, but in this case the declaration of pre- and post- blocks can probably always be done inside an if {${subport} ne "py-${name}"} conditional. Handling that main port with a simple trailing

if {${subport} eq "py-${name}"} {
    PortGroup stub 1.0
}

would still be more elegant. And it could even be relegated to the python PG callback, I suppose, which would be even more elegant. But even I wouldn't qualify this a "particularly inconvenient" situation. As far as I can oversee anyway :)

[RJVB (René Bertin)]

To piggyback this ticket about the stub PG: I just noticed that it doesn't prevent ports using a different fetch.type to perform a full fetch.

It could be argued that port maintainers will just have to handle that, but it'd be easy to catch it in the PG with a single additional line:

`

distfiles

+ fetch.type standard

patchfiles

`

[ryandesign (Ryan Carsten Schmidt)]

In 0da0f7f584b3373d74cd1a8f76879d7558405aad/macports-ports (master):

stub-1.0.tcl: Use fetch.type standard

See: #70077