Обсуждение: RHEL5 postgresql94-contrib is broken, unsatisfied dependency on uuid-ossp

Hi all

The package  postgresql94-contrib-9.4beta2-1PGDG.rhel5.i386 is broken;
it has an undeclared dependency on  libossp-uuid.so.15 that cannot be
satisfied without enabling EPEL, which PGDG doesn't depend on.

Error: Package: postgresql94-contrib-9.4beta2-1PGDG.rhel5.i386 (pgdg94)
           Requires: libossp-uuid.so.15

UUID support should be disabled, or libossp-uuid should be included in
pgdg for RHEL5 and declared as a dependency in the package. The current
situation is broken.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 08/19/2014 11:50 PM, Craig Ringer wrote:
> Hi all
>
> The package  postgresql94-contrib-9.4beta2-1PGDG.rhel5.i386 is broken;
> it has an undeclared dependency on  libossp-uuid.so.15 that cannot be
> satisfied without enabling EPEL, which PGDG doesn't depend on.
>
> Error: Package: postgresql94-contrib-9.4beta2-1PGDG.rhel5.i386 (pgdg94)
>            Requires: libossp-uuid.so.15
>
> UUID support should be disabled, or libossp-uuid should be included in
> pgdg for RHEL5 and declared as a dependency in the package. The current
> situation is broken.

Andres points out offlist that contrib/uuid no longer requires ossp-uuid
in 9.4 anyway; libuuid may be used.

In old releases that was part of e2fsprogs . In RHEL5 it appears in
e2fsprogs-libs .

I haven't done a test build yet, but perhaps that dependency can just be
replaced with libuuid from e2fsprogs-libs and an appropriate
package-level dependency. Sure, it's a weird dependency, but it saves
depending on EPEL for this.

Comments?

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On Aug 19, 2014, at 9:38 AM, Craig Ringer <craig@2ndQuadrant.com> wrote:

> On 08/19/2014 11:50 PM, Craig Ringer wrote:
>> Hi all
>>
>> The package  postgresql94-contrib-9.4beta2-1PGDG.rhel5.i386 is broken;
>> it has an undeclared dependency on  libossp-uuid.so.15 that cannot be
>> satisfied without enabling EPEL, which PGDG doesn't depend on.
>>
>> Error: Package: postgresql94-contrib-9.4beta2-1PGDG.rhel5.i386 (pgdg94)
>>           Requires: libossp-uuid.so.15
>>
>> UUID support should be disabled, or libossp-uuid should be included in
>> pgdg for RHEL5 and declared as a dependency in the package. The current
>> situation is broken.
>
> Andres points out offlist that contrib/uuid no longer requires ossp-uuid
> in 9.4 anyway; libuuid may be used.
>
> In old releases that was part of e2fsprogs . In RHEL5 it appears in
> e2fsprogs-libs .
>
> I haven't done a test build yet, but perhaps that dependency can just be
> replaced with libuuid from e2fsprogs-libs and an appropriate
> package-level dependency. Sure, it's a weird dependency, but it saves
> depending on EPEL for this.

I think we've always had a soft dependency on EPEL.  I thought it was mentioned on the site, but now I don't see it, so
maybeI'm wrong. 

Hopefully Devrim will get back to a keyboard soon as I'm about to head to the airport and will have to follow up on
thisnext week. 

On 08/20/2014 04:22 AM, Jeff Frost wrote:
> On Aug 19, 2014, at 9:38 AM, Craig Ringer <craig@2ndQuadrant.com> wrote:
>> I haven't done a test build yet, but perhaps that dependency can just be
>> replaced with libuuid from e2fsprogs-libs and an appropriate
>> package-level dependency. Sure, it's a weird dependency, but it saves
>> depending on EPEL for this.
>
> I think we've always had a soft dependency on EPEL.  I thought it was mentioned on the site, but now I don't see it,
somaybe I'm wrong. 

It's unfortunate that all of -contrib depends on that just for uuid;
it'd be IMO much better to have separate:

   postgresql94-contrib
   postgresql94-contrib-uuid

if the dependency is needed.

Also, the dependency is undeclared and added by rpm's find-deps. There's
no explicit RPM-level dependency, just a shared object dependency. So at
least some users will have no idea how to find this "libossp-uuid.so.15"
that we require.

Anyway - looks like it can be avoided for 9.4 now, even on old RHEL.


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Hi,

On Tue, 2014-08-19 at 23:50 +0800, Craig Ringer wrote:
> The package  postgresql94-contrib-9.4beta2-1PGDG.rhel5.i386 is broken;
> it has an undeclared dependency on  libossp-uuid.so.15 that cannot be
> satisfied without enabling EPEL, which PGDG doesn't depend on.

We have to depend on EPEL. I have unofficially declared this before.
Maybe I should add a text to web page?

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

Hi,

On Wed, 2014-08-20 at 09:58 +0800, Craig Ringer wrote:
> It's unfortunate that all of -contrib depends on that just for uuid;
> it'd be IMO much better to have separate:
>
>    postgresql94-contrib
>    postgresql94-contrib-uuid
>
> if the dependency is needed.

That has been discussed before, but I personally do not want to split
the packages more.

> Also, the dependency is undeclared and added by rpm's find-deps.

We can fix it by adding a Requires: line.

>  There's no explicit RPM-level dependency, just a shared object
> dependency. So at least some users will have no idea how to find this
> "libossp-uuid.so.15" that we require.

Right. Let's fix it in the next set of releases.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/26/2014 12:05 AM, Devrim Gündüz wrote:
> We have to depend on EPEL. I have unofficially declared this
> before. Maybe I should add a text to web page?

Probably a good idea.

There's actually no need to depend on ossp in 9.4 though, we can just
build against e2fs uuid, which is present even in RHEL. I have that
change in my local spec tree and it's working well so far, still some
testing to do.

- --
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJT+/j/AAoJELBXNkqjr+S2bPYH/3PakXCVz4Sq1pYUJtbsNDgr
RwpRCrbInH4lEQUxKFjF23t9C1Cz2DcqterPld59HZirHbm65M4ToRibrGqaKUfR
JABXYJtOzkEca/EO3WXMKn3BTUzpektNvfRaK7tqS0vdMXIlHHTklAGX1FaJV6Ex
/0kMRRfKtUuf/w+iYbErQPpUpM7MvtfPFJuvCVz5IUOkkbbTpMAFFR2fsHrRnafo
wztTJR6PX5RKKYDzuhH67YjT5O1q8viwR9fX9lNhlNGYqXiAJvfLZ2UUTCZvLzkG
nO1phz2SpZGcZ4IY+KgDXo933q9x8MZfisvvuB7aqjU6wsJBIwx2Wb/7sQJTM9w=
=LbiQ
-----END PGP SIGNATURE-----

On 08/26/2014 12:07 AM, Devrim Gündüz wrote:
>> >  There's no explicit RPM-level dependency, just a shared object
>> > dependency. So at least some users will have no idea how to find this
>> > "libossp-uuid.so.15" that we require.
> Right. Let's fix it in the next set of releases.

Sounds good - A Requires: plus some references to EPEL being recommended
for RHEL/CentOS would do the job.

We don't need it for 9.4 though; the conditional uuid support may be
removed entirely and replaced with:


# Over time the package containing this has varied.  If in doubt use:
#   yum whatprovides /usr/lib64/libuuid.so
# to find out.
%if 0%{?rhel} == 5
BuildRequires: e2fsprogs-devel
%else
BuildRequires: libuuid-devel
%endif

and instead of --with-ossp-uuid to configure, use:

    --with-uuid=e2fs


then there's no need for core postgresql94 packages to depend on EPEL at
all anymore.


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Hi,

On Wed, 2014-08-27 at 12:08 +0800, Craig Ringer wrote:

> > Right. Let's fix it in the next set of releases.
>
> Sounds good - A Requires: plus some references to EPEL being recommended
> for RHEL/CentOS would do the job.

Ok.

> We don't need it for 9.4 though; the conditional uuid support may be
> removed entirely and replaced with:
>
>
> # Over time the package containing this has varied.  If in doubt use:
> #   yum whatprovides /usr/lib64/libuuid.so
> # to find out.
> %if 0%{?rhel} == 5
> BuildRequires: e2fsprogs-devel
> %else
> BuildRequires: libuuid-devel
> %endif
>
> and instead of --with-ossp-uuid to configure, use:
>
>     --with-uuid=e2fs
>
>
> then there's no need for core postgresql94 packages to depend on EPEL at
> all anymore.

Do you have time to submit a patch to current spec files? Otherwise, I
can give a shot next week.

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 08/29/2014 07:40 PM, Devrim Gündüz wrote:
> Do you have time to submit a patch to current spec files? Otherwise, I
> can give a shot next week.

Done.

I've prepped a patch incorporating some of the changes from the unified
spec, sticking to bug fixes and an update to beta2, per the changelogs.

To reduce the chance of mistakes in repetitive editing of each spec,
where possible I made the changes to one spec then patched the others to
match. Doesn't it drive you a bit nuts having to make the same change
five times?

The diffstat for each spec is slightly different - comments in EL-5
explaining why libe2fs-devel is used; addition of perl MODULE_COMPAT in
EL-5 and EL-6 where it was missing, etc.

I've test-built each spec, but haven't installed and manually tested
them each out, and my Vagrant test harness code isn't ready for stock
PGDG RPMs yet. I assume you already have test scripts that will be
suitable anyway.


pg_upgrade support is still broken, per
http://www.postgresql.org/message-id/53DBA105.3080004@2ndquadrant.com

I also have no way to fix the java dependency bug as it's caused by
build-time problems.

Patch prepared from git-svn. I've pushed it to my working branch in case
you want to inspect it more easily too. (About that git migration...)


These packages now build without errors under mock. The stock mock
configurations shipped with Fedora 20 for RHEL/CentOS have EPEL enabled,
which seems like what you'd want, but no EPEL packages will actually get
pulled in for these builds anyway.


yum install mock spectool rpmdevtools yum-utils

cd 9.4/postgresql
(cd EL-5 && spectool --gf postgresql-9.4.spec)
for d in EL-6 EL-7 F-19 F-20; do
    cp EL-5/postgresql-9.4-A4.pdf d/
    cp EL-5/postgresql-9.4beta2.tar.bz2 d/
done

then create build.sh:

#!/bin/bash
target=$1
distdir=$2
mock -r $target \
  --buildsrpm \
  --spec $distdir/postgresql-9.4.spec --source $distdir/
cp /var/lib/mock/$target/result/*.src.rpm $distdir/
export RPM_BUILD_NCPUS=4
mock -r $target \
   --rebuild $distdir/*.src.rpm
cp /var/lib/mock/$target/result/*.rpm $distdir/

then:

bash build.sh epel-5-i386 EL-5
bash build.sh fedora-20-x86_64 F-20

... and so on. No more need for individual build boxes.

(I haven't attached the much more complete build-and-sign-and-upload
script I use because it's currently tied up in some BDR specifics,
assumes that there's only one spec file for all target distros, and it
requires a patched mock (albeit trivially patched). Anyway, it'd be
better to go straight to using Koji).


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 09/01/2014 02:52 PM, Craig Ringer wrote:
> On 08/29/2014 07:40 PM, Devrim Gündüz wrote:
>> Do you have time to submit a patch to current spec files? Otherwise, I
>> can give a shot next week.

Was this the patch you were looking for?

Any concerns?

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Hi,

On Mon, 2014-09-01 at 14:52 +0800, Craig Ringer wrote:

> I've prepped a patch incorporating some of the changes from the
> unified spec, sticking to bug fixes and an update to beta2, per the
> changelogs.

The patch did not apply to my copy, since it seems you did not have the
latest version. Anyway, I applied only some parts of the patch:

* changing buildrequires for uuid support.
* removal of /var/log/pgsql
* removing provides for libpq.so

I did not apply:

* I am not in favor of removing uuid conditional. Some people may be
using it.

* I did not apply the _isa related part. Packages like OpenOffice.org
requires "postgresql-libs" for example, and that is all. If we provide
the full version, we may break them (at least this is what I noticed a
year or two ago)

All changes are in [720] .

> To reduce the chance of mistakes in repetitive editing of each spec,
> where possible I made the changes to one spec then patched the others
> to match. Doesn't it drive you a bit nuts having to make the same
> change five times?

Well, I think I am used to it. :-)

> The diffstat for each spec is slightly different - comments in EL-5
> explaining why libe2fs-devel is used; addition of perl MODULE_COMPAT
> in EL-5 and EL-6 where it was missing, etc.

FWIW, I have committed perl MODULE_COMPAT changes last week or so.

> pg_upgrade support is still broken, per
> http://www.postgresql.org/message-id/53DBA105.3080004@2ndquadrant.com

I'm at London this week, that is why some of your email are still
pending for review.

> I also have no way to fix the java dependency bug as it's caused by
> build-time problems.

I'll look at it later.

Thanks for the patch!

Cheers,


--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 09/03/2014 06:09 PM, Devrim Gündüz wrote:
> On Mon, 2014-09-01 at 14:52 +0800, Craig Ringer wrote:
>
>> I've prepped a patch incorporating some of the changes from the
>> unified spec, sticking to bug fixes and an update to beta2, per the
>> changelogs.
>
> The patch did not apply to my copy, since it seems you did not have the
> latest version.

I forgot to "git svn rebase" after I fetched changes. Whoops. Sorry.

> I did not apply:
>
> * I am not in favor of removing uuid conditional. Some people may be
> using it.

No complaint here. It seemed useless to have it when it'll build
unconditionally now, as if it's defined but no longer used it'll just
get ignored by RPM. But I don't have any complaint about keeping it,
it's just noise.

> * I did not apply the _isa related part. Packages like OpenOffice.org
> requires "postgresql-libs" for example, and that is all. If we provide
> the full version, we may break them (at least this is what I noticed a
> year or two ago)

There are two separate things in that change, and I probably should've
sent a patch series. I'm just not used to working with svn, even via
git-svn.


The extra %{?_isa} Provides: should be applied, as they're an
incompatibility between PGDG RPMs and Red Hat's. RPM automatically adds
these Provides to a package, but not to explicit Provides: lines. So
right now:

$ repoquery -q --provides postgresql
postgresql = 9.3.5-1.fc20
postgresql(x86-32) = 9.3.5-1.fc20

but:

$ sudo repoquery -q --provides postgresql93
postgresql
postgresql93 = 9.3.5-1PGDG.f20
postgresql93(x86-64) = 9.3.5-1PGDG.f20

and IMO, that's wrong. We should at minimum provide "postgresql(x86-32)".

Adding new Provides: cannot cause incompatibilities, so I think the
(versioned) %{?_isa} provides should be added to improve compatibility
with stock Fedora. However, since nobody's actually complaining about
them being missing, it's a bit academic until other packagers start
fixing their packages to follow Fedora packaging guidelines and add
%{?_isa} to their arch-sensitive Requires: lines like for postgresql-libs .



Separately, there's versioning the existing Provides: lines. I'm quite
confident that can't cause incompatibilities either as a versioned
Provides: satisfies an unversioned Requires: but not vice-versa, and
IIRC a versioned Requires: is not satisfied by an unversioned Provides .
So I'll follow up on this once I've done som VM testing.

>> pg_upgrade support is still broken, per
>> http://www.postgresql.org/message-id/53DBA105.3080004@2ndquadrant.com
>
> I'm at London this week, that is why some of your email are still
> pending for review.

Thanks. I know there's no real rush, I'm just in a position where I have
time to do some of this at the moment.

>> I also have no way to fix the java dependency bug as it's caused by
>> build-time problems.
>
> I'll look at it later.

Thanks.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services