On Thu, Feb 27, 2020 at 12:45:51PM -0800, Freddie Cash wrote: > On Thu, Feb 27, 2020, 12:37 PM Willem Jan Withagen, <w...@digiware.nl> wrote: > > > > > Interesting, but not quite what I want.... > > It is not for personal usage, but for ports that I have commited to the > > ports collection, and want to upgrade. > > And yes, fixing openssl works for this problem, but it is not only my > > problem. > > > > I maintain these Ceph ports, and now upstream uses a python module that > > expects SSlv3 to be available in the openssl that encounters on the system. > > And the question is how to accommodate that? > > Short of embedding my own openssl libs with the ceph-libs, thus creating > > a huge maintenance problem. > > > > I could also argue that switching of SSLv3 in a generic library is sort > > of impractical, even if it is a protocol that we want to erradicate. > > But I guess that the maintainers of openssl have decided that this is > > the smart thing to do. > > And I'm in peace with that, but now require an escape from this catch-22. > > > > --WjW > > > > There's no mechanism in the ports tree framework for port X to depend on > feature Y being enabled in port Z. > > All you can do is add a pkg-message alert to your ceph port saying the use > needs to compile the openssl port with SSLv3 enabled. > > You could create a slave port for openssl that has that option enabled, > then depend on that slave port. But that might create dependency issues > elsewhere.
You can do it, but nobody will commit that kind of change. The choice of which OpenSSL version to use is a user facing change, and it is done globally. As a side note, SSLv3 is going away, anything done right now that needs it is doomed. > Sub-packages might (eventually) allow you to work around this. As probably the only one who knows the subpackages implementation, I don't see how it possibly could. -- Mathieu Arnold
signature.asc
Description: PGP signature
