On Saturday May 30 2015 05:53:08 Ryan Schmidt wrote: > Even introducing a stub portgroup would be preferable to repeating this code > everywhere.
++ > I don't like the name "stub port" because it is confusingly similar to > "subport" which is a different concept. But not all stub ports are meta ports > so we can't just call them meta ports. Dummy port? Placeholder port? > Right, that's done a lot, for example in all the py-*, p5-* and php-* ports. > But that's the type of port I think of as not being a meta port. Maybe I'm > overthinking the terminology, but I'm differentiating between a port that > does nothing but depend on more than one other port for the purpose of making > it easier to install a collection of ports (like the gimp port), and a port > that does nothing but install a default subport of itself (e.g. the py, p5, > php ports, etc.) You're not wrong; at least the description of such a port should make it clear what it does, so that the user doesn't have to look at the dependencies to figure it out. How in fact does it work when the default subport is upgraded, say from py27 to py3x, if those subports are mutually exclusive? If this involves marking the py27 subport as replaced_by the newer version, can one still decide to install the py27 subport (supposing it still works of course)? R. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
