> On 18 Mar 2015, at 5:52pm, Arno Hautala <[email protected]> wrote: > > On Wed, Mar 18, 2015 at 1:20 PM, René J.V. <[email protected]> wrote: >> On Wednesday March 18 2015 12:10:07 Arno Hautala wrote: >> >> So, no, there should be no fear of non-reproducible builds, at least not if >> I got in all the dependencies :) >> >>> Regardless, I'd think the configure would still need to be set up to >>> only use the internal or MacPorts versions. >> >> Which is what it does. > > Cool. I wonder if there's still an issue of sometimes using internal > versions and sometimes using MacPorts, but as the internal versions > aren't available yet, it seems like a minor issue if any. My internal > pedant would want the configure to explicitly use the internal > versions and explicitly select the available MacPorts versions, but > the pedant must be crushed.
No, I would agree with you. Even if no ports for the various used ‘local’ components exist, for future protection the audacity port should be configured to *always* use its internal versions, regardless of what might or might not be available via macports (or worse elsewhere). That way the builds remain predictable. If at some point ports for one or other of these internal components become available, then the audacity port can be, if desired, updated to depend upon and use that port. Everything remains deterministic, which is how it should be. Chris > > Thanks for posting. I look forward to it being approved. > > --Arno > > -- > arno s hautala /-| [email protected] > > pgp b2c9d448 > _______________________________________________ > macports-users mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-users
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
