From: Pavel Raiskup <praiskup@redhat.com>
To: pgsql-pkg-yum@lists.postgresql.org
Cc: Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= <devrim@gunduz.org>,
 pgsql-pkg-yum <pgsql-pkg-yum@postgresql.org>
Subject: Re: [Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs -
 create libpq.spec and libecpg.spec instead]
Date: Fri, 17 Aug 2018 15:12:34 +0200
Message-ID: <4157216.yXmPSteUxy@nb.usersys.redhat.com>
In-Reply-To: <e5def31a137f24ca2b8ac16a1e296c4245679a3c.camel@gunduz.org>
References: <bug-1618698-153952@bugzilla.redhat.com>
 <e5def31a137f24ca2b8ac16a1e296c4245679a3c.camel@gunduz.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

On Friday, August 17, 2018 2:20:20 PM CEST Devrim G=FCnd=FCz 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@redhat.com
> To: devrim@gunduz.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
>=20
> > https://bugzilla.redhat.com/show_bug.cgi?id=3D1618698
> >=20
> >             Bug ID: 1618698
> >            Summary: [modularity] drop postgresql-libs - create libpq.sp=
ec
> >                     and libecpg.spec instead
> >            Product: Fedora
> >            Version: rawhide
> >          Component: postgresql
> >           Keywords: FutureFeature, Tracking
> >           Assignee: praiskup@redhat.com
> >           Reporter: praiskup@redhat.com
> >         QA Contact: extras-qa@fedoraproject.org
> >                 CC: anon.amish@gmail.com, devrim@gunduz.org,
> >                     hhorak@redhat.com, jmlich83@gmail.com,
> >                     jstanek@redhat.com, pkajaba@redhat.com,
> >                     pkubat@redhat.com, praiskup@redhat.com,
> >                     tgl@sss.pgh.pa.us
> >=20
> >=20
> >=20
> > Fedora (28+) already provides multiple versions of PostgreSQL packages,=
 the
> > default version AND the modular version (even though DB team has not st=
arted
> > maintaining the modular PG stack, it's done by modularity people - avai=
lable
> > for testing in /etc/yum.repos.d/fedora-modular.repo).
> >=20
> > 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!).
> >=20
> > 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 Fe=
dora
> > 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).
> >=20
> > 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 p=
arty
> > modules built against that server).
> >=20
> > The major change in 'postgresql.spec' is that we'll drop shared librari=
es
> > 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 th=
at,
> > even though servers will be distributed in multiple versions, the _clie=
nt_
> > library can be built and maintained only once per system.
> >=20
> > 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 ver=
sion
> > of
> > PostgreSQL server module in the middle of Fedora stable release.  For t=
his
> > 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 vers=
ioned
> > ABI of the libpq library.
> >=20
> > This approach (single version of libpq and ABI versioning) has been
> > discussed upstream and the result is that:
> >=20
> >   - 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)
> >=20
> >   - upstream is not ATM very much interested in ABI versioning support
> >=20
> > If upstream decided to implement ABI versioning one day, we'd migrate to
> > that scheme in the next branched distro version.
> >=20
> > [1]
> >=20
> https://www.postgresql.org/message-id/5261375.z5KIV9Ssac%40nb.usersys.red=
hat.com
> >=20
> > This bug is meant to serve the tracking purpose.
> >=20
>=20
>=20