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