<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 05.08.2020 um 14:52 schrieb Georges Martin <<a href="mailto:jrjsmrtn@gmail.com" class="">jrjsmrtn@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">If MacPorts starts to mix both approaches, I worry we may end up having (open source) packages depending on closed source, binary packages. And have less control on ensuring a consistent, compatible distribution.</span></div></blockquote></div><div class=""><br class=""></div><div class="">That's already the case e.g. with port that use one of the openjdk* ports as dependency. Also, basically all ports using portgroup java depend on a binary java distribution. I'd rather see the dependencies being part of the macports tree, so we can at least control versions and variants, than trying to keep the depending ports out of MP.</div><div class=""><br class=""></div><div class="">To minimize this risk, I guess Macports could exclude binary ports from being used as dependencies to other ports. As soon as such ports are reliably recognizable, that is. There should be a way to allow such dependencies on a port by port basis, though.</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>