public inbox for [email protected]
help / color / mirror / Atom feedFrom: Pavel Raiskup <[email protected]>
To: [email protected]
Cc: Devrim Gündüz <[email protected]>
Cc: pgsql-pkg-yum <[email protected]>
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: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
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: [email protected]
> To: [email protected]
> 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: [email protected]
> > Reporter: [email protected]
> > QA Contact: [email protected]
> > CC: [email protected], [email protected],
> > [email protected], [email protected],
> > [email protected], [email protected],
> > [email protected], [email protected],
> > [email protected]
> >
> >
> >
> > 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.
> >
>
>
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: [Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs - create libpq.spec and libecpg.spec instead]
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox