Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 May 2016 11:27:23 +0200
From:      Palle Girgensohn <girgen@FreeBSD.org>
To:        Baptiste Daroussin <bapt@FreeBSD.org>
Cc:        pgsql@FreeBSD.org, ports@FreeBSD.org
Subject:   Re: coinstallable version of pgsql (POC)
Message-ID:  <6F16C952-B7FA-4945-A1CC-DDF45E17DFA0@FreeBSD.org>
In-Reply-To: <20160506233512.GC84309@ivaldir.etoilebsd.net>
References:  <20160506233512.GC84309@ivaldir.etoilebsd.net>

next in thread | previous in thread | raw e-mail | index | archive | help

> 7 maj 2016 kl. 01:35 skrev Baptiste Daroussin <bapt@FreeBSD.org>:
>=20
> Hi all,
>=20
> Apparently noone had time to work on making all the version of pgsql
> coinstallable since we last talked about it
>=20
> Here is a proof of concept done on pg95 which makes it coinstallable:
> https://people.freebsd.org/~bapt/pgsql95.diff
>=20
> It is unfinished given I have not enough time for that.
>=20
> Basically it keeps the package split as it is now (PoC done on =
clients, server,
> contrib and plperl) for server what remains is renaming the rc.d =
script
>=20
> all binaries are now installed under lib/postgresql95/bin and a =
symlink in
> regular bin suffixed by the version number.
>=20
> the rpath from the default built is disabled and replaced with a new =
one which
> ensure the order of the rpath is correct (the default one is not in =
the right
> order) which ensure the libpq version found in priority is the the =
right
> version. using rpath is good here to avoid adding a ldconfig file =
which would
> make other programs accidentally find the non default libpq
>=20
> In order to keep the manpages, in category 1 the manpages have been =
renamed to
> match the name of the symlinks in the PATH
>=20
> In the 7 category thet have been suffixed with postgresql${version} so =
one can
> really have all the manpages for all clients available and clearly =
state which
> one correspond to which version
>=20
> the man3 and pkgconfig has been removed as they belong to the libpq =
package
>=20
> What is missing: create a new postgresql-libq based on latest pg =
version which
> is installed in the default lib directory
>=20
> What I forgot here is to add a BUNDLE_LIBS=3Dyes for the solver never =
to take in
> accoung libpq.so.5 from those clients
>=20
> Last thing would be to cleanup Mk/Uses/pgsql.mk to allow parallel =
installation
>=20
> I really hope you like that approach and that someone will be able to =
finish it
> soon.
>=20
> That would be really helpful for users to be able to decide which =
version of pg
> they want without having to build their own packages.
>=20
> It will also simplify upgrading as at one point one have tools from =
all version
> of postgresql available at once.
>=20
> Best regards,
> Bapt

Hi Bapt,

Sounds great. As you write, noone had enough time. I did some work but =
the last couple of months nothing really happened.

I'll have a look at your diff promptly!

My approach was that the client always defaults to the latest released =
version of PostgreSQL. That is, even if you install postgresql93-server, =
it will pull in postgresql95-client. The client is backwards compatible =
apart from very weird corner cases, like direct Kerberos login (not =
gssapi) that was removed in 8.x or something.=20

This is what Debian does and it works for them. We should keep old =
client versions around for the anxious, but they could actually =
conflict, i.e. we install the server and contrib in parallel, but not =
the client. That would fix the hassle of symlinks.

Palle






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6F16C952-B7FA-4945-A1CC-DDF45E17DFA0>