On 12/27/20 4:49 PM, Dan Mahoney (Gushi) wrote:
Hey there all.
[...]
Here are the questions I can't seem to answer:
1) There's no make.conf entry to override the openssl ciphers. This
needs to be done at the port level. (Probably reasonable, I don't think
there should be an insecure "flavor") But in the interest of making
things reproducible, is there a "Standard" way to keep this consistent
without running "make config" every time, or echo'ing options into
/var/db/ports/security-openssl/options?
2) I'm unclear as to what to put in make.conf to tell ONE PORT to use
the openssl from ports, while I want all the others to use base. I know
this is in some cases askign for trouble, but the nagios plugins are
standalone binaries. Is there some method in make.conf or on the port
command line to tell ONE PORT to use a defaults+=ssl-openssl without
making it the default for ALL PORTS?
3) If I do all that, ports seems to lack a standard way to build static
binaries, which is what I'd really like. Is there an easy way to do
this, or is it best to work outside the ports system at that point?
-Dan
Not judging. I am always in some sort of disagreement with the
otherwise world-class ports+poudriere system of FreeBSD package
management. Like, now, texlive. And I locally maintain a
fluctuating group that occasionally has members migrate back
into mainstream ports because my disagreement is no longer
material.
If I was in your situation, I would start with whatever version of
openssl works best for the obsolete packages you want to link/plugin
against. Stuff the source down into /usr/local/pkg/repo/openssl1,
write some 15 liner shell scripts to configure, build, and install
it to /usr/local/pkg/lib. In my experience one needs to fixup
PREFIX and occasionally rpaths. Other hacks go into a git branch
in the repo. Setup your path for your obsolete packages user
account and off you go. (Could be some dependency hell in your
future, I would keep it simple.)
*or*
Install an ancien version of FreeBSD that does what you want
in a vm. No idea how to deal with the packages for that system,
maybe it's trivial. This method is how I deal with Unifi software
(on old debian versions) after battling the outdated "*" problem
for years. Works great with bhyve. If I want a current version
of something that doesn't work great in the obsolete version and
is orthogonal to the support task at hand I generally just try to
configure, build, and install it to... /usr/local/pkg in the vm
Compared to dealing with this before, now my life is awesome.
OMG I forgot FreeBSD => jails. I don't use jails but that would
be the quickest route here I'm guessing.
I am assuming here that you don't need any big frameworks, because
then I doubt it would make sense at all to battle the problem this
way.
Good luck!
Russell
_______________________________________________
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"
