Обсуждение: How to Build Postgres in a Portable / Relocatable fashion?
Back in the good old days there was official 1st-party support for Linux:
Those binaries could be
tar xvf'd and used without any fuss or muss, from any location, on any distro.I'm the core maintainer of https://webinstall.dev/ and I'm thinking to break our "official builds only" rule because, well, I haven't been able to find any way to get up-to-date builds from an official channel - and
apt is always half-a-decade out-of-date (part of the reason for Webi, but Webi is far worse in this case, stuck at v10).Could I get some help on how to do that?
Are the old build processes documented somewhere? Or are there some scripts in a far corner of the Internet that could still do that?
Or what options might I need to pass to ./configure to get it to build with relative locations?
I'm not a C developer, and I'm not familiar with C build tools beyond
./configure; make; sudo make install.I'd really appreciate some direction on this. Thanks.
AJ ONeal
On 5/3/24 15:57, AJ ONeal wrote: > Back in the good old days there was official 1st-party support for Linux: Still there. The below is for the EDB installer, which at this point is only for MacOS and Windows as Unixen platforms have there own packaging. This was/is a third party site. > https://www.enterprisedb.com/downloads/postgres-postgresql-downloads > <https://www.enterprisedb.com/downloads/postgres-postgresql-downloads> > > Those binaries could be |tar xvf|'d and used without any fuss or muss, > from any location, on any distro. > > I'm the core maintainer of https://webinstall.dev/ > <https://webinstall.dev/> and I'm thinking to break our "official builds > only" rule because, well, I haven't been able to find any way to get > up-to-date builds from an official channel - and |apt| is always > half-a-decade out-of-date (part of the reason for Webi, but Webi is far > worse in this case, stuck at v10). I don't see that. Using PGDG repo on Ubuntu 22.04: apt list --installed | grep postgres postgresql-14/jammy-pgdg,now 14.11-1.pgdg22.04+1 amd64 [installed] postgresql-15-pgtap/jammy-pgdg,now 1.3.3-1.pgdg22.04+1 all [installed] postgresql-15/jammy-pgdg,now 15.6-1.pgdg22.04+1 amd64 [installed] postgresql-16-pgtap/jammy-pgdg,now 1.3.3-1.pgdg22.04+1 all [installed] postgresql-16-unit/jammy-pgdg,now 7.8-1.pgdg22.04+1 amd64 [installed] postgresql-16/jammy-pgdg,now 16.2-1.pgdg22.04+1 amd64 [installed,automatic] postgresql-client-14/jammy-pgdg,now 14.11-1.pgdg22.04+1 amd64 [installed,automatic] postgresql-client-15/jammy-pgdg,now 15.6-1.pgdg22.04+1 amd64 [installed,automatic] postgresql-client-16/jammy-pgdg,now 16.2-1.pgdg22.04+1 amd64 [installed,automatic] postgresql-client-common/jammy-pgdg,now 259.pgdg22.04+1 all [installed,automatic] postgresql-common/jammy-pgdg,now 259.pgdg22.04+1 all [installed,automatic] postgresql-plpython3-14/jammy-pgdg,now 14.11-1.pgdg22.04+1 amd64 [installed] postgresql-plpython3-15/jammy-pgdg,now 15.6-1.pgdg22.04+1 amd64 [installed] postgresql-plpython3-16/jammy-pgdg,now 16.2-1.pgdg22.04+1 amd64 [installed] postgresql-server-dev-16/jammy-pgdg,now 16.2-1.pgdg22.04+1 amd64 [installed] postgresql/jammy-pgdg,now 16+259.pgdg22.04+1 all [installed] > > Could I get some help on how to do that? > Are the old build processes documented somewhere? Or are there some > scripts in a far corner of the Internet that could still do that? As to Apt build scripts: https://wiki.postgresql.org/wiki/Apt/RepoDocs > > Or what options might I need to pass to ./configure to get it to build > with relative locations? > I'm not a C developer, and I'm not familiar with C build tools beyond > |./configure; make; sudo make install|. > > I'd really appreciate some direction on this. Thanks. > > AJ ONeal -- Adrian Klaver adrian.klaver@aklaver.com
> > Back in the good old days there was official 1st-party support for Linux: > This > was/is a third party site. Oh. I thought that EDB was *the* Postgres company like MySQL AB was *the* MySQL company. My mistake. > and `apt` is always half-a-decade out-of-date I misspoke. I meant the OS repos more than apt itself. > As to Apt build scripts: I was just using apt as an example. I don't actually want to deal with apt or .debs. What I want to create (and provide) is a portable tarball that has most of all what it needs in the tarball and will lookfor relevant libraries relative to itself. Something that Just Works™ *almost* anywhere (Ubuntu, Debian, RedHat, Suse...maybe even Alpine). Any idea how to do that?
AJ ONeal <coolaj86@proton.me> writes: > What I want to create (and provide) is a portable tarball that has > most of all what it needs in the tarball and will look for relevant > libraries relative to itself. See https://www.postgresql.org/docs/current/installation.html particularly the discussion of installation relocatability under https://www.postgresql.org/docs/current/install-make.html#CONFIGURE-OPTIONS-LOCATIONS In short, you have to specify an installation path, but as long as you don't muck with the relative locations of the subdirectories it should be possible to move the whole tree to a different installation location. > Something that Just Works™ *almost* anywhere (Ubuntu, Debian, RedHat, Suse... maybe even Alpine). That's a little harder, mainly because the shared libraries for dependencies like openssl etc may not be 100% compatible across all those platforms. Different versions, different build options, yadda yadda. Maybe you should be thinking in terms of a docker container or the like? regards, tom lane
On Fri, May 3, 2024 at 11:27:12PM +0000, AJ ONeal wrote: > > > Back in the good old days there was official 1st-party support for Linux: > > This > > was/is a third party site. > > Oh. I thought that EDB was *the* Postgres company like MySQL AB was *the* MySQL company. My mistake. How did you come to that conclusion? Is there something we could do to avoid this assumption. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
> > What I want to create (and provide) is a portable tarball that has > > most of all what it needs in the tarball and will look for relevant > > libraries relative to itself. > > > See > > https://www.postgresql.org/docs/current/installation.html > > particularly the discussion of installation relocatability under > > https://www.postgresql.org/docs/current/install-make.html#CONFIGURE-OPTIONS-LOCATIONS It seems like the first bit of magic I need is: `--prefix=/doesntexist/postgres` Including 'postgres' as part of the name puts it in "relative mode", so-to-speak. Thank you! > > Something that Just Works™ almost anywhere (Ubuntu, Debian, RedHat, Suse... maybe even Alpine). > > > That's a little harder, mainly because the shared libraries for > dependencies like openssl etc may not be 100% compatible across > all those platforms. Different versions, different build options, > yadda yadda. I'd like to build as much static as possible (or reasonable). Is there a way to tell it "just include openssl"? > Maybe you should be thinking in terms of a docker container > or the like? I really hate Docker. The idea of "we can't ship your computer to the client, so we'll just ship... a clone of you computerto the client" offends my sensibilities. Or rather, I like the opportunity that LXC provides in the right context, but I don't like how it's become a replacementfor shared knowledge within a group - i.e. "no one can remember the wisdom of the ancients, so if this fragilesystem that Ted built ever fails or needs a change no one knows how he did it or what the options mean, but don'tworry, it's all encapsulated in a very complex Dockerfile that no one understands and depends on hundreds of layersof images... but it's not like someone would ever leftpad any of them... What could go wrong?"
On 5/3/24 17:07, Bruce Momjian wrote: > On Fri, May 3, 2024 at 11:27:12PM +0000, AJ ONeal wrote: >>>> Back in the good old days there was official 1st-party support for Linux: >>> This >>> was/is a third party site. >> >> Oh. I thought that EDB was *the* Postgres company like MySQL AB was *the* MySQL company. My mistake. > > How did you come to that conclusion? Is there something we could do to > avoid this assumption. > From here: https://www.enterprisedb.com/ #1 IN POSTGRES THE MOST ADMIRED, DESIRED, & USED DATABASE. is not helpful. Though I would say the bigger issue is here: https://www.postgresql.org/download/ Where you have Packages and Installers and then further down 3rd party distributions It tends to imply that the 'Packages and Installers' are not third party, when they are to some degree or another. -- Adrian Klaver adrian.klaver@aklaver.com
On Fri, May 3, 2024 at 05:29:34PM -0700, Adrian Klaver wrote: > From here: > > https://www.enterprisedb.com/ > > #1 IN POSTGRES > THE MOST ADMIRED, DESIRED, & USED DATABASE. > > is not helpful. > > Though I would say the bigger issue is here: > > https://www.postgresql.org/download/ > > Where you have > > Packages and Installers > > and then further down > > 3rd party distributions > > It tends to imply that the 'Packages and Installers' are not third party, > when they are to some degree or another. I think it is that way because we don't have any guarantees or regular communication with "3rd party distributions". -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
On 5/3/24 17:35, Bruce Momjian wrote: > On Fri, May 3, 2024 at 05:29:34PM -0700, Adrian Klaver wrote: >> From here: >> >> https://www.enterprisedb.com/ >> >> #1 IN POSTGRES >> THE MOST ADMIRED, DESIRED, & USED DATABASE. >> >> is not helpful. >> >> Though I would say the bigger issue is here: >> >> https://www.postgresql.org/download/ >> >> Where you have >> >> Packages and Installers >> >> and then further down >> >> 3rd party distributions >> >> It tends to imply that the 'Packages and Installers' are not third party, >> when they are to some degree or another. > > I think it is that way because we don't have any guarantees or regular > communication with "3rd party distributions". > I would say it is not clear enough that Core is responsible for the source releases, anything above that is some other groups responsibility. This becomes apparent when you have to tell people that fixing packaging issues requires reaching out to said groups through means that are not entirely clear. -- Adrian Klaver adrian.klaver@aklaver.com
AJ ONeal <coolaj86@proton.me> writes:
> It seems like the first bit of magic I need is:
> `--prefix=/doesntexist/postgres`
No, you want an actual path so that "make install" will succeed.
The point is that then you can tar up that installation tree
(relative to its top) and untar it somewhere else.
> I'd like to build as much static as possible (or reasonable). Is there a way to tell it "just include openssl"?
No, and are you really sure you want that? Then it's on you to
rebuild and redistribute, pronto, every time openssl issues a security
fix. There's a reason why most Linux distros forbid static linking of
libraries from different sources.
regards, tom lane
Re: How to Build Postgres in a Portable / Relocatable fashion?
От
grimy.outshine830@aceecat.org
Дата:
On Fri, May 03, 2024 at 11:27:12PM GMT, AJ ONeal wrote: > What I want to create (and provide) is a portable tarball that has > most of all what it needs in the tarball and will look for relevant > libraries relative to itself. Something that Just Works™ *almost* > anywhere (Ubuntu, Debian, RedHat, Suse... maybe even Alpine). Alpine is based on musl (not glibc), so you're pretty much OOL at least on that point. Have you thought about using a container? -- Ian