Re: Splitting libpq build - Mailing list pgsql-general

Hi, Tom,

On Sun, Oct 3, 2021 at 5:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Igor Korot <ikorot01@gmail.com> writes:
> > Imagine you are a developer/maintainer of sme software. This software needs to
> > connect to different DBMSes perform soe operations and then disconnect.
> > It is very easy to say that I have SQLite as a submodule in my Git tree,
> > I have mysql-connector as a submodule, but I can't have libpq this way
> > because it is hidden deep down inside PostgreSQL sources.
>
> To be blunt, that is an absolutely horrid way to distribute software.
> You should not, not, not be redistributing other people's code,
> because that puts you on the hook to keep up with their bug fixes ---
> particularly security-critical fixes, which do happen from time to time.
> That's a loop you don't want to be in.

I am not.
I don't know if you are familiar, but Git has a notion of using submodules
Which means all I as a developer can do is to say "My program is using moduleA,
moduleB and moduleC". And if the user configure my program not to use
system libraries
but use mine instead (maybe because mine is newer?), I'll let them.

>
> In this case I don't even see what's the point.  If somebody wants to
> use your code with Postgres, it's just about certain that they already
> have an installed copy of libpq, from wherever they get Postgres from.
> The same argument applies to mysql or SQLite.  So you should be
> expecting to link against already-present libraries, not bring your
> own.  Do you bring your own libc, or openssl, or C compiler?

Imagine a situation where someone is using Ubuntu 16 and libpq 5.
I can provide a newer version of libpq because it has security fixes
and sme additional features.
Remember - release life cycle for different distros are different.
And what about Windows?
Usually when you work with Windows you lin statically.
Therefore it doesn't matter much - you provide the code that the user builds
and that's it.

>
> I can tell you for certain that if your package were to be picked up
> and redistributed by Red Hat, or Debian, or any other open-source
> vendor, the very first thing they'd do is strip it of any such copied
> code.  They don't want the management hassle of having to update
> multiple copies of libpq or mysql-connector or other stuff.

Agreed.
But my repository will not contain a copy of libpq - it will merely be
pointing to
the original source code of the library.
See the difference?
And if the user wants to clone my repository - great.
He will just grab the cde from the PostgreSQL repo and build it as
part of the build process.

Thank you.

>
>                         regards, tom lane