On Monday April 04 2016 16:22:27 Rainer Müller wrote: >A user already installed port A with the official port group foo-1.0. >Then they add a new source, overriding the port group foo-1.0, which >redefines some paths. This will not cause A to be outdated and no >rebuild of A will be triggered. Now installing B, which depends on A, >will use the new port group. The result is unspecified and the build >would also most likely fail.
Yes, I already pointed that out in a previous message. 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. >Note this will already be a problem if you tell users to replace port >groups in the official tree. Yep. And as I also noted, providing an official way to override PortGroups will make it easier to debug the situation when something goes wrong and the log contains a clear indication that a custom PortGroup was used. It might even be possible to disregard anything from var/macports/sources/PortGroups that is not registered to an installed port(?). >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 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). 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). >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.) >However, if you copy the port into the customized ports tree with the >new port group, custom binary archives can always be distributed from >the corresponding archive_sites for this ports tree. Sure, I could just fork of all MacPorts while I'm at it ... >should be checked. Falling back to the default might use a binary >archive with incompatible contents. It's possible I've been bitten by that once or twice, typically because I forgot the -n with an `upgrade --force`. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
