On 2016-04-04 17:13, René J.V. Bertin wrote: > On Monday April 04 2016 16:22:27 Rainer Müller wrote: > This should *not* be the case if the current lookup rules for > _resources continue to be applied, but a higher priority central > location (var/macports/sources/PortGroups) is added where copies of > (symlinks to) PortGroups are installed. In that scenario, foo-1.0 > will only be replaced when the user installs the custom port A. > Nothing will change if the custom source contains a rogue foo-1.0 > PortGroup that does not belong to a variant of port A, or if that > custom port A is never installed.
As Clemens said, PortGroups need to be available to parse a port. They cannot be installed with a port. You would have to keep one version in the ports tree and then another one that is installed by a port. That breaks reproducibility of *any* operation on a Portfile using this port group, as the result of parsing may be completely different. In fact, this might not even define a port with the same name anymore. Your case with a custom port group providing an additional variant seems so special that I doubt it is really worth or possible to develop a generic solution. >> needed, or the version of the port group could be changed. > > Changing a PortGroup version is a no-go as far as I'm concerned, as > it makes it impossible to build existing ports against an alternative > PortGroup without modification. As a PortGroup is merely an include, changing the port group means changing the Portfile. As the input for parsing the Portfile changes, this would still be a modified port. >> As soon as a port group was overridden for a port we would have to >> disable binary archives completely for this port. > > Not necessarily, and in fact that depends more on the associated > *port* than on the PortGroup. My custom cmake PortGroup for instance > doesn't introduce any incompatible changes (except possibly for ports > that happen not to be built as intended with the current PortGroup > ... but those ports are buggy anyway). >From my point of view, port groups do not belong to any specific port. It is just an additional input for the build. Even if the port group is still compatible, we cannot determine that programmatically. Thus, the only and safest option would be to disable them altogether as soon as a PortGroup is overridden. > In practice, it's what I enforce in my own alternative Qt5 PortGroup, > but only if the associated port is installed (in that case a variant > is declared and set default, which doesn't disable binary archives > but changes the binary requirements to something non-existing). That sounds quite fragile... >> binary? What if a ports uses multiple port groups from different >> trees? > > To repeat myself: don't forget that those trees are usually developed > by people who use them themselves. If their use-case includes copying > PortGroups to the main tree, they thus have every interest to protect > themselves against that kind of eventuality, like I did with the > aforementioned variant. (I did more in fact; my Qt5 port also tries > very hard to work with mainstream binary packages of dependent > ports.) You might have tried to do that, but if the goal is to make it easier to plug-in additional external repositories, we have to think of the generic case. Rainer _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
