Re: [Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs - create libpq.spec and libecpg.spec instead]

On Friday, August 17, 2018 2:20:20 PM CEST Devrim Gündüz wrote:
> Comments, please?

Since pgrpms are parallel installable, and use completely different package
names - that Fedora change should make no noise here.

In case something in PGRPMS is built against system-default libpq.so.5, the
built packages might get generated slightly different Requires - but it
should be for good.

I have a playground here, but it's a WIP!
https://copr.fedorainfracloud.org/coprs/praiskup/libpq/
https://copr.fedorainfracloud.org/coprs/praiskup/libpq-postgresql-10/

Any comment is welcome here as well :-), thanks for bringing this up!

Pavel

> -------- Forwarded Message --------
> From: bugzilla(at)redhat(dot)com
> To: devrim(at)gunduz(dot)org
> Subject: [Bug 1618698] New: [modularity] drop postgresql-libs - create
> libpq.spec and libecpg.spec instead
> Date: Fri, 17 Aug 2018 11:18:09 +0000
>
> > https://bugzilla.redhat.com/show_bug.cgi?id=1618698
> >
> > Bug ID: 1618698
> > Summary: [modularity] drop postgresql-libs - create libpq.spec
> > and libecpg.spec instead
> > Product: Fedora
> > Version: rawhide
> > Component: postgresql
> > Keywords: FutureFeature, Tracking
> > Assignee: praiskup(at)redhat(dot)com
> > Reporter: praiskup(at)redhat(dot)com
> > QA Contact: extras-qa(at)fedoraproject(dot)org
> > CC: anon(dot)amish(at)gmail(dot)com, devrim(at)gunduz(dot)org,
> > hhorak(at)redhat(dot)com, jmlich83(at)gmail(dot)com,
> > jstanek(at)redhat(dot)com, pkajaba(at)redhat(dot)com,
> > pkubat(at)redhat(dot)com, praiskup(at)redhat(dot)com,
> > tgl(at)sss(dot)pgh(dot)pa(dot)us
> >
> >
> >
> > Fedora (28+) already provides multiple versions of PostgreSQL packages, the
> > default version AND the modular version (even though DB team has not started
> > maintaining the modular PG stack, it's done by modularity people - available
> > for testing in /etc/yum.repos.d/fedora-modular.repo).
> >
> > The ongoing plan is to support the modular PostgreSQL server, too, and make
> > that server interchangeable with system-default version (note that this is
> > not about parallel install-ability/SCL!).
> >
> > The new layout should be 100% compatible with what we have provided so far,
> > so regular user shouldn't really observe big differences. I.e. each Fedora
> > version should still (by default) provide/install the latest PostgreSQL
> > major server version which was available at the time of Fedora branching
> > (from Fedora Rawhide).
> >
> > So the change is that, in module repository (in module streams), we'll
> > provide different versions of set of PostgreSQL server packages
> > (postgresql-server, postgresql-contrib, postgresql-pl*, etc., + third party
> > modules built against that server).
> >
> > The major change in 'postgresql.spec' is that we'll drop shared libraries
> > from there - the postgresql-libs subpackage. Newly the contents of
> > postgresql-libs subpackage will be provided in 'libpq' and 'libecpg'
> > packages (with *-devel counterparts). The benefit of this layout is that,
> > even though servers will be distributed in multiple versions, the _client_
> > library can be built and maintained only once per system.
> >
> > We expect to provide older PG stack version usually in modules, but it _is_
> > expected (we at least wish) that we could even start shipping newer version
> > of
> > PostgreSQL server module in the middle of Fedora stable release. For this
> > purpose, we might need to have libpq updated to newer major version (if the
> > newly provided server version will require a newer libpq, e.g. because there
> > are newer symbols). So to automatically guard against server/client-lib
> > mis-installation, we'll start with small downstream change -- with versioned
> > ABI of the libpq library.
> >
> > This approach (single version of libpq and ABI versioning) has been
> > discussed upstream and the result is that:
> >
> > - Debian packagers do something similar (slightly differently because
> > they maintain several libpq.so.5 versions in parallel, but only
> > the latest required libpq is installed)
> >
> > - upstream is not ATM very much interested in ABI versioning support
> >
> > If upstream decided to implement ABI versioning one day, we'd migrate to
> > that scheme in the next branched distro version.
> >
> > [1]
> >
> https://www.postgresql.org/message-id/5261375.z5KIV9Ssac%40nb.usersys.redhat.com
> >
> > This bug is meant to serve the tracking purpose.
> >
>
>