public inbox for [email protected]
help / color / mirror / Atom feed[Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs - create libpq.spec and libecpg.spec instead]
2+ messages / 2 participants
[nested] [flat]
* [Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs - create libpq.spec and libecpg.spec instead]
@ 2018-08-17 12:20 Devrim Gündüz <[email protected]>
2018-08-17 13:12 ` Re: [Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs - create libpq.spec and libecpg.spec instead] Pavel Raiskup <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Devrim Gündüz @ 2018-08-17 12:20 UTC (permalink / raw)
To: pgsql-pkg-yum
Comments, please?
-------- 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.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> Unsubscribe from this bug
> https://bugzilla.redhat.com/token.cgi?t=pnHwxgRavl&a=cc_unsubscribe
--
Devrim Gündüz
EnterpriseDB: https://www.enterprisedb.com
PostgreSQL Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs - create libpq.spec and libecpg.spec instead]
2018-08-17 12:20 [Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs - create libpq.spec and libecpg.spec instead] Devrim Gündüz <[email protected]>
@ 2018-08-17 13:12 ` Pavel Raiskup <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Pavel Raiskup @ 2018-08-17 13:12 UTC (permalink / raw)
To: [email protected]; +Cc: Devrim Gündüz <[email protected]>; pgsql-pkg-yum
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.
> >
>
>
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2018-08-17 13:12 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-08-17 12:20 [Fwd: [Bug 1618698] New: [modularity] drop postgresql-libs - create libpq.spec and libecpg.spec instead] Devrim Gündüz <[email protected]>
2018-08-17 13:12 ` Pavel Raiskup <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox