coinstallable version of pgsql (POC)

[Baptiste Daroussin]

On Sat, May 07, 2016 at 11:27:23AM +0200, Palle Girgensohn wrote:
> 
> > 7 maj 2016 kl. 01:35 skrev Baptiste Daroussin <bapt at FreeBSD.org>:
> > 
> > Hi all,
> > 
> > Apparently noone had time to work on making all the version of pgsql
> > coinstallable since we last talked about it
> > 
> > Here is a proof of concept done on pg95 which makes it coinstallable:
> > https://people.freebsd.org/~bapt/pgsql95.diff
> > 
> > It is unfinished given I have not enough time for that.
> > 
> > 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
> > 
> > all binaries are now installed under lib/postgresql95/bin and a symlink in
> > regular bin suffixed by the version number.
> > 
> > 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
> > 
> > In order to keep the manpages, in category 1 the manpages have been renamed to
> > match the name of the symlinks in the PATH
> > 
> > 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
> > 
> > the man3 and pkgconfig has been removed as they belong to the libpq package
> > 
> > What is missing: create a new postgresql-libq based on latest pg version which
> > is installed in the default lib directory
> > 
> > What I forgot here is to add a BUNDLE_LIBS=yes for the solver never to take in
> > accoung libpq.so.5 from those clients
> > 
> > Last thing would be to cleanup Mk/Uses/pgsql.mk to allow parallel installation
> > 
> > I really hope you like that approach and that someone will be able to finish it
> > soon.
> > 
> > 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.
> > 
> > It will also simplify upgrading as at one point one have tools from all version
> > of postgresql available at once.
> > 
> > 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.

Yeah we all have that time problem. I just restarted on it due to a new comer
yelling at pkg not being allowed to use postgresql95 with official binary
packages, but I do not really have time to finish it as well :(
> 
> I'll have a look at your diff promptly!
> 
Thanks

> 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. 
> 
> 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.

Yes I tried that and I have been bitten once by that approach long ago when
upgrading the server iirc I do not remember this was few years ago so it might
not be accurate anymore.

I remmeber the official linux packages from postgresql has the issue with the
rpath I fixed here: using the libpq from /usr/lib instead of the one they do
bundle
> 
> Palle
> 
> 
Thanks!

Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20160507/b7a1fb5d/attachment.sig>