about alternative ports and the build bots

[Jeremy Huddleston Sequoia]

The issue exists in more general form for cases like ffmpeg and ffmpeg-devel when the dylib id changes (eg: when bumping it due to binary incompatibility).  If the user goes and installs ffmpeg-devel, then anything that depends on ffmpeg needs to be built from source because the buildbot produces content linked against ffmpeg.

I don't think there's really any way around this with MacPorts currently.

> On Sep 28, 2015, at 06:59, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> Hi,
> 
> I'd like to bring up something related to alternative ports and the build bots. It concerns my qt5-kde port (submitted on trac), but the principle is more generic.
> 
> In short, consider 2 ports that are supposed to be alternatives like port:foo and port:foo-devel, but that are different enough in where they install libraries that their binary forms are not drop-in replacements, and that cannot of course be installed concurrently. To keep this generic, let's assume there's a port:foo-mac which adheres to a Mac-inspired install layout and port:foo-xdg which adheres to a layout that's compatible with the ones used on Linux and other Unixes. Let's also assume that there as always been a foo PortGroup that takes care of defining variables for the various install locations, and that sets up a path: style dependency on port:foo (or one of its alternatives). This PortGroup has been split into foo-mac, foo-kde PortGroups and a general foo PortGroup that can include the appropriate foo "sub PortGroup" as a function of what the user has installed or a preference declared by a dependent port.
> 
> So when building a port that depends on foo:
> - if foo-xdg is installed and foo.prefer_mac isn't defined, use the foo-xdg PortGroup
> - else if foo-mac is installed and foo.prefer_xdg isn't defined, use the foo-mac PortGroup
> - else if foo.prefer_xdg is defined, use the foo-xdg PortGroup
> - else use the foo-mac PortGroup
> 
> From this it should follow that any port that does not declare a preference will use the foo-mac PortGroup (pulling it in if necessary) unless the user already installed port:foo-xdg .
> 
> If no binary builds existed, this should more or less cover all possible cases. It would be nice to have the option to "prefer the one but can make do with the other too" vs. "require the one over the other" (aborting when the requirement is not met), but if that's even possible it can be a next evolution.
> 
> Binary builds exist however, so something should be done to prevent pulling in a binary build for (against) foo-mac when foo-kde is installed, and vice-versa. I think I have a solution for that, which should work if my assumption is correct that binary packages are built each starting with a virgin MacPorts install, i.e. pulling in only the required dependencies.
> It works like this: the foo-xdg defines a `fooxdg` variant (if it doesn't exist already), and makes it default. That way, any port that "inherits" port:foo-xdg without requesting it specifically will get a (default) variant that exists only on the user's end and not on the build bots, and therefore, `port install somePortDependsOnFoo` will be a request for somePortDependsOnFoo+fooxdg, leading to an install-from-source. On the other hand, a port that prefers/requests foo-xdg will have the +fooxdg variant set as a default also on the buildbots, and thus be available as a binary build against port:foo-xdg .
> 
> The default_variant could be set only when the variant is defined in the PortGroup or when foo.prefer_xdg is set, but I do not currently see why that would be necessary or preferable.
> However, I'm not sure how best to ensure that someone with port:foo-mac installed will not end up installing a binary package that is built against port:foo-xdg , and I think that isn't already ensured. Maybe those ports should simply do a pre-fetch check if foo-xdg is indeed the one installed (via a proc to be provided by the foo-xdg PortGroup)?
> 
> 
> I think this is completely orthogonal to questions about reproducible builds, before anyone mentions that principle :) and I can only hope that this is not "MacPorts doesn't support this". (The real-world implementation of port:foo-xdb, port:qt5-kde, is quite likely to be a requirement for KF5 ports currently in preparation.)
> 
> Thoughts and feedback welcome!
> 
> R.
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150928/07ea6d5a/attachment-0001.p7s>