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. Sub-packages might (eventually) allow you to work around this. Cheers, Freddie Typos due to smartphone keyboard. > _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
