<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2 Oct 2021, at 8:06 pm, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" class="">ken.cunningham.webuse@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">That is exactly the approach that I don't find workable, Chris.<div class=""><br class=""></div><div class="">Specifically:</div><div class=""><br class=""></div><div class="">1. every single port (think: rust, ghc, blah blah) will have to be needlessly managed to build against an alternate openssl location.</div></div></div></blockquote><div><br class=""></div>why ? They can start of using the shim port and only use the isolated builds as and when they are ready</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">2. there will be no default openssl ever in prefix.</div></div></div></blockquote><div><br class=""></div>why not ? The boost set has one and I see no reason why openssl cannot as well.</div><div><br class=""></div><div>Chris</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">So I am not on board for trying to implement that myself, but should that be the selected course I will watch from the sidelines as others proceed down that path.</div><div class=""><br class=""></div><div class="">K</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 2, 2021, at 12:02 PM, Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" class="">jonesc@hep.phy.cam.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div dir="ltr" class=""></div><div dir="ltr" class="">Hi,</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Personally I would strongly recommend following a migration path that does not require an enmass change but allows ports to migrate at their own pace. I would personally very much recommend an approach similar to that we used for boost recently</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">1. Introduced a set of new isolated opensslXYZ ports that install specific versions into isolated install areas under libexec.</div><div dir="ltr" class="">2. Create a new portgroup that handles the confirmation of ports to pick the openssl version they wish to use, with some default, and performs various standard configurations for standard build systems such that for most ports they work out the box with the new portgroup. For those that don’t provide various proc methods that return the configured install paths such that ports can used them to configure themselves as required.</div><div dir="ltr" class="">3. Make the current openssl port a basic shim port that just installs sym links into the primary install area to the default openssl version (for now 1.1.1), so ports building against the current openssl port carry on working just as they are now, but are redirected to use the same versioned 1.1.1 port as those using the PG.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Once this is in place, ports can be migrated to use the new PG individually as and when we want.</div><div dir="ltr" class=""><br class=""></div><div dir="ltr" class="">Chris</div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On 2 Oct 2021, at 6:17 pm, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" class="">ken.cunningham.webuse@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">openssl 3.0.0 is out, with a new and very favourable Apache-2 license that will let many previously non-distributable ports become distributable. However, there are 758 ports that indicate they link against openssl. That is a daunting number of ports indeed.<div class=""><br class=""></div><div class="">One option might be to move all of our openssl ports (1.0, 1.1, and 3.x) into subdirectories out of ${prefix}, have no default openssl installed in $[prefix} directly, create a new PortGroup, openssl_select or some such, add that PG to all 758 ports, default it to openssl 1.1.1, and then allow people to gradually move the 758 ports to openssl 3.0.0 as they get to it.</div><div class=""><br class=""></div><div class="">Although that is possible with suitable effort, I don’t think that is workable for many reasons, the most obvious being that we would then have to modify every single port in some way to find an openssl installed into a non-default prefix. Creating the PG and adding it to 758 ports might be work enough, but then finding the right way to force all 758 ports to build properly against an openssl that is not in the default prefix is the real horror, and seems like a nightmare of wasted labours.</div><div class=""><br class=""></div><div class="">So it would appear that the same option that was chosen last time, ie upgrade the default openssl in ${prefix} to the newer openssl, and then fix the subset of ports that will not build against it to use an older openssl appears both the better option and lot less work (assuming most ports do build against openssl 3.0.0, which seems to be the case so far). Some will disagree, but I put it to you that it is going to be far less work in the end to force a few % of the ports to a specific alternate openssl than force all of them, all the time, forever.</div><div class=""><br class=""></div><div class="">Most things I have attempted to rebuild over the past few days have rebuilt without any issues, but a few things don’t build with openssl 3.0.0 yet and will need to stay with openssl 1.1.1 for a while until patched or updated (or forever). That will require both forcing those ports to find an alternate openssl installation, and also (the tricky part) forcing them to ignore the openssl in the default prefix.</div><div class=""><br class=""></div><div class="">To support this, there is a new openssl11 port that provides openssl 1.1.1 tucked away in a subdir, much like we have openssl10, and a few new options were added to the old_openssl PortGroup to allow most ports to be forced to the alternate openssl with minimal fuss. Add the PortGroup, spec the branch, and choose the method, for the most part.</div><div class=""><br class=""></div><div class="">If this plan holds, I would anticipate that we move ports that we find need to stay on openssl 1.1.1 to openssl11 using the old_openssl PortGroup soon or now, before we upgrade to openssl 3.0.0 to minimize fuss. Then once we have done that, upgrading the default openssl to 3.0.0 and revbumping the deps would occur.</div><div class=""><br class=""></div><div class="">So I am asking that anyone with an interest in a port that uses openssl please try building it against openssl 3.0.0 in the PR below, and if there is a problem that can’t be solved by an update or a patch, consider trying to use the old_openssl PortGroup to fix the build and move it over. As there are so many ports, it would help if people pitched in with the ones that are important to them.</div><div class=""><br class=""></div><div class="">The openssl 3.0.0 upgrade PR is here:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/macports/macports-ports/pull/12410" class="">https://github.com/macports/macports-ports/pull/12410</a></div><div class=""><br class=""></div><div class="">and my own WIP repo of a few ports that I have found won’t build with openssl 3.0.0 at present and fixed to use the old_openssl PG is here:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/kencu/mybigsuroverlay/" class="">https://github.com/kencu/mybigsuroverlay/</a></div><div class=""><br class=""></div><div class="">the idea is that the ports in that repo would be moved into the main repo as we work through the main ones that use openssl at least.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">K</div><div class=""><br class=""></div><div class="">PS. One thing I have not yet sorted out how to do is how to support libressl in the setting of needing to force a port to openssl 1.1.1 using the old_openssl PortGroup. Open to any thoughts on this. This case wsa basically just ignored last time with openssl10, and we may have to do the same again unless someone has a bright idea.</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></body></html>