Обсуждение: Providing libpq explicitly
Hi Craig, Around Sep 2014, I committed a patch of yours that remove explicit Provides: libpq.so from the PostgreSQL RPMs, for 9.4 beta2. Do you remember the reason behind this? For 3rd party apps that depend on specific version of libpq (I mean like "libpq >= 9.1", not libpq.so.5) are broken now. Would you mind if I put it back to the community RPMs? Thanks! Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
On 10 October 2016 at 14:44, Devrim Gündüz <devrim@gunduz.org> wrote: > > Hi Craig, > > Around Sep 2014, I committed a patch of yours that remove explicit > > Provides: libpq.so > > from the PostgreSQL RPMs, for 9.4 beta2. Do you remember the reason behind > this? Honestly, I don't have the foggiest anymore. > For 3rd party apps that depend on specific version of libpq (I mean like "libpq >>= 9.1", not libpq.so.5) are broken now. Would you mind if I put it back to the > community RPMs? I'd argue that such packages are simply incorrectly packaged. There's no such thing as "libpq 9.1". They should be using rpm's automatic library dependencies to ensure that dependency, and shouldn't declare an explicit dependency. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Hi Craig, On Mon, 2016-10-10 at 15:20 +0800, Craig Ringer wrote: > I'd argue that such packages are simply incorrectly packaged. There's > no such thing as "libpq 9.1". Well, this actually "works". This means "libpq provided by PostgreSQL 9.1 RPMs", for example, and prevents users to be able to install PostgreSQL < 9.0: ========================================= Requires: libpq.so >= 9.0 Available: postgresql-libs-8.4.20-6.el6.i686 (base) libpq.so = 8.4.20-6.el6 You could try using --skip-broken to work around the problem. ========================================= > They should be using rpm's automatic library dependencies to ensure > that dependency, and shouldn't declare an explicit dependency. Then, they would need to generate RPMs for each PostgreSQL version just for this piece, and it creates other problems. Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
On 10 October 2016 at 15:28, Devrim Gündüz <devrim@gunduz.org> wrote: > > Hi Craig, > > On Mon, 2016-10-10 at 15:20 +0800, Craig Ringer wrote: >> I'd argue that such packages are simply incorrectly packaged. There's >> no such thing as "libpq 9.1". > > Well, this actually "works". This means "libpq provided by PostgreSQL 9.1 > RPMs", for example, and prevents users to be able to install PostgreSQL < 9.0: > > ========================================= > Requires: libpq.so >= 9.0 > Available: postgresql-libs-8.4.20-6.el6.i686 (base) > libpq.so = 8.4.20-6.el6 > You could try using --skip-broken to work around the problem. > > ========================================= >> They should be using rpm's automatic library dependencies to ensure >> that dependency, and shouldn't declare an explicit dependency. > > Then, they would need to generate RPMs for each PostgreSQL version just for > this piece, and it creates other problems. Huh? Why? If the soname is the same (which it must be for linking to work) and the target library version is >= the one it was built against (which it should be to be compatible) then it'll be fine. Otherwise it won't work because it shouldn't work. At minimum it should be Provides: libpq not Provides: libpq.so . But in the end, since I can't even remember the original reason to get rid of it, if you put it back it's your call. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 10/10/16 2:44 AM, Devrim Gündüz wrote: > For 3rd party apps that depend on specific version of libpq (I mean like "libpq >> >= 9.1", not libpq.so.5) are broken now. Would you mind if I put it back to the > community RPMs? What is an example of such a package? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, 2016-10-10 at 21:59 -0400, Peter Eisentraut wrote: > What is an example of such a package? One of EDB packages. It uses functions exported by the libpq of 9.1+. Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
Вложения
On 11 October 2016 at 15:13, Devrim Gündüz <devrim@gunduz.org> wrote: > On Mon, 2016-10-10 at 21:59 -0400, Peter Eisentraut wrote: >> What is an example of such a package? > > One of EDB packages. It uses functions exported by the libpq of 9.1+. I see, and you don't want to depend on postgresql9x-libs because you want to allow install against any postgresql9x-libs that installs a libpq. It's a binary distribution issue. Fair enough. You could have alternatives listed in Requires, but that requires enumerating all postgresql9x variants into the future, which is messy and fragile. What should IMO be done here is to add a version on the Provides: postgresq-llibs that already exists: $ rpm -q --provides postgresql96-libs config(postgresql96-libs) = 9.6beta3-1PGDG.f23 libecpg.so.6()(64bit) libecpg_compat.so.3()(64bit) libpgtypes.so.3()(64bit) libpq.so.5()(64bit) libpqwalreceiver.so()(64bit) postgresql-libs postgresql96-libs = 9.6beta3-1PGDG.f23 postgresql96-libs(x86-64) = 9.6beta3-1PGDG.f23 I think it's also fine to have a versioned Provides: libpq but *not* Provides: libpq.so, because that should be rpm autodeps job. That's likely why I asked for its removal originally; as I said I just don't remember anymore. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 10/11/16 3:33 AM, Craig Ringer wrote: > On 11 October 2016 at 15:13, Devrim Gündüz <devrim@gunduz.org> wrote: >> > On Mon, 2016-10-10 at 21:59 -0400, Peter Eisentraut wrote: >>> >> What is an example of such a package? >> > >> > One of EDB packages. It uses functions exported by the libpq of 9.1+. > I see, and you don't want to depend on postgresql9x-libs because you > want to allow install against any postgresql9x-libs that installs a > libpq. Surely the RPM world has a standard or convention for this so we don't have to make up something here? This is not the first shared library in the world, after all -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi, On Wed, 2016-10-12 at 09:37 -0400, Peter Eisentraut wrote: > > I see, and you don't want to depend on postgresql9x-libs because you > > want to allow install against any postgresql9x-libs that installs a > > libpq. > > Surely the RPM world has a standard or convention for this so we don't > have to make up something here? This is not the first shared library in > the world, after all Noticing that we already provide postgresql-libs (versionless), I made a small change in the spec file, and appended version number to that provides. It won't break our packages, and then make EDB's package happy. So, no changes in libpq.so part. Thank you! Regards, -- Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR