Daniele Varrazzo <daniele.varrazzo@gmail.com> writes:
> I have a problem building binary packages for psycopg2. Binary
> packages ship with their own copies of libpq and libssl; however if
> another python package links to libssl the library will be imported
> twice with conflicting symbols, likely resulting in a segfault (see
> https://github.com/psycopg/psycopg2/issues/543). This happens e.g. if
> a python script both connects to postgres and opens an https resource.
Basically, you're doing it wrong. Shipping your own copy of libssl,
rather than depending on whatever packaging the platform provides,
is just asking for pain --- and not only of this sort. You're also
now on the hook to update your package whenever libssl fixes a bug
or a security vulnerability, which happens depressingly often.
The same applies to libpq, really. You don't want to be in the
business of shipping bits that you are not the originator of.
When I worked at Red Hat, there was an ironclad policy against
building packages that incorporated other packages statically.
I would imagine that other distros have similar policies for
similar reasons. Just because you *can* ignore those policies
doesn't mean you *should*.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
