Date: Sat, 7 May 2016 13:11:57 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Palle Girgensohn <girgen@FreeBSD.org> Cc: ports@FreeBSD.org, pgsql@FreeBSD.org Subject: Re: coinstallable version of pgsql (POC) Message-ID: <20160507111157.GD84309@ivaldir.etoilebsd.net> In-Reply-To: <6F16C952-B7FA-4945-A1CC-DDF45E17DFA0@FreeBSD.org> References: <20160506233512.GC84309@ivaldir.etoilebsd.net> <6F16C952-B7FA-4945-A1CC-DDF45E17DFA0@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--IDYEmSnFhs3mNXr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 07, 2016 at 11:27:23AM +0200, Palle Girgensohn wrote: >=20 > > 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 on= e 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 ren= amed 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 stat= e which > > one correspond to which version > >=20 > > the man3 and pkgconfig has been removed as they belong to the libpq pac= kage > >=20 > > What is missing: create a new postgresql-libq based on latest pg versio= n which > > is installed in the default lib directory > >=20 > > What I forgot here is to add a BUNDLE_LIBS=3Dyes for the solver never t= o take in > > accoung libpq.so.5 from those clients > >=20 > > Last thing would be to cleanup Mk/Uses/pgsql.mk to allow parallel insta= llation > >=20 > > I really hope you like that approach and that someone will be able to f= inish it > > soon. > >=20 > > That would be really helpful for users to be able to decide which versi= on 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 >=20 > Hi Bapt, >=20 > Sounds great. As you write, noone had enough time. I did some work but th= e last couple of months nothing really happened. Yeah we all have that time problem. I just restarted on it due to a new com= er 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 :( >=20 > I'll have a look at your diff promptly! >=20 Thanks > My approach was that the client always defaults to the latest released ve= rsion of PostgreSQL. That is, even if you install postgresql93-server, it w= ill pull in postgresql95-client. The client is backwards compatible apart f= rom very weird corner cases, like direct Kerberos login (not gssapi) that w= as removed in 8.x or something.=20 >=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. 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 mi= ght not be accurate anymore. I remmeber the official linux packages from postgresql has the issue with t= he rpath I fixed here: using the libpq from /usr/lib instead of the one they do bundle >=20 > Palle >=20 >=20 Thanks! Best regards, Bapt --IDYEmSnFhs3mNXr+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXLc19AAoJEGOJi9zxtz5aNRwQAMbgKI0UXsN8C0/aUsezdRsH dJgwWKL5jlgJukSroF+/llbdRwj5LNkPTS1/bVw3gB1qhNFAbzg6iP6ud726Mr6S aZ/y+cA4Q6U4eOLGf3QdDbJXRakYpO+OeHFiyk5V+AsxOFunAe8Ca7wAlhcD8ZBU ba8l791rip3dTy5OeuB6XIj+b85OwNkkSXn34muD6PHYhE5SpXDpC9iEI8K7/zKe F4auCkvO2C/RSV3NjwXiEYlYHLmPfkyC8tmU4uxSVhPDdxbLGdLQJeGHZaCZLPjo B1TVlp3yZ02LukRhNrLSzwqWHClH/2tqfUrR9VgQC86NgqZ83NoSi/LVjTyDQVvM veYJ4UmK2bbQ2OctlMLiUvelrmOygN99zM5cBJ3Ix9D5l4UmMShbGYi5Y8IFHDoy kmAz0LdpjfpvLfUb4aRiZn4SbPD5EeXi2o0/ffY5Ore1uvTLKtikoS0PWGvkknId dquML51U6f/X3ZYJSMrLcwKFG1hEdtwmciQn3EYd9A6O5TN4jwCD8OAJ98uh6us7 L+hdm516icimbqitmNo6vn4zrzYV19baUswdnFEvIMiY1ZXyanrPRF8P1MMk9n1U XT6MmRaGYvzbbj6tP+z8/XrBR9yX2C8zLkN6Ztv1L/5NyV0mWCGNeKM0sX5bqEal Zcb4XQ4mkEYVWz0CbJer =xKNM -----END PGP SIGNATURE----- --IDYEmSnFhs3mNXr+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160507111157.GD84309>