On Fri, Oct 27, 2017 at 2:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniele Varrazzo <daniele.varra...@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*.
Distros do compile the library from source and against the system package, and everyone using the package directly can still do so; the binary packages are only installed by the Python package manager. Psycopg is more complex to install than the average Python package (it needs python and postgres dev files, pg_config available somewhere etc) and a no-dependencies package provides a much smoother experience. It also happens that the libpq and libssl versions used tend to be more up-to-date than the system one (people can already use the new libpq 10 features without waiting for debian packages). I am confronted with the reality of Python developers as of 201x's, and shipping binary packages has proven generally a positive feature, even factoring in the need of shipping updated binary packages when the need arises. The benefit of a simple-to-use library is for the Postgres project at large, it is not for my personal gain. So while I know the shortcomings of binary packages and static libraries, I would still be interested in knowing the best way to fix the problem in the subject. Feel free to write in private if you want to avoid the public shaming. -- Daniele -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
