Re: Distributing a partially-compatible variant package?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/22/2014 10:14 AM, Craig Ringer wrote:
Hi all

I have a somewhat odd requirement that I'm finding it hard to fit into
RPM's framework.

TL;DR: I need to release a variant of a package that's compatible with
extensions compiled for it as shared libraries, with its client library,
and with its network protocol - but *isn't* compatible with the on disk
file format it uses. How do you handle such partial compatibility?



I need to distribute a patched PostgreSQL that can be used in place of
the normal PostgreSQL packages (by PGDG, from
http://yum.postgresql.org/) for the purposes of satisfying dependencies.
These upstream packages have the form:

Name:    postgresql94
Version: 9.4beta2
Release: 1PGDG

The variant packages I need to publish are not totally compatible with
the unmodified PostgreSQL on-disk format, so they can't just have a:

Provides: postgresql94 = 9.4beta2

entry, because that can cause them to be installed instead of the PGDG
packages if users have both my repository and the upstream PGDG one
enabled and do a

     yum install postgresql94

Because of the incompatible on disk format, that's undesirable.

However, these packages have libraries compatible with those in stock
PostgreSQL, a compatible network protocol, etc. In all ways except the
on disk format they meet the requirements of applications that depend on
PostgreSQL, and there's a large repository of packaged extensions and
utilities I'd like to re-use without having to repackage and re-compile
it all. They all have Requires: postgresql94 and expect to install
libraries into certain specific locations so PostgreSQL can find them.

That means I have to use the same binary paths, etc, so my packages will
conflict with the stock ones.

What I've done is produced packages with a new name based on the "bdr"
variant I need to package, like:

Name:      postgresql-bdr94
Version:   9.4beta2_bdr1
Release:   1_2ndQuadrant
Provides:  postgresql94%{?isa}
Conflicts: postgresql94%{?isa}

that Provides the package I seek to replace, but also Conflicts with it.
Without the Provides entry packages of extensions etc will refuse to
install. Without the Conflicts entry yum will try to install
postgresql-bdr94 side-by-side with postgresql94 then rpm will abort the
install when it finds out that they share most of the same file locations.

I can't use Obsoletes, or use Provides without Conflicts, because the
new package isn't totally compatible with the old one and it'd be a
nasty surprise to users if the new package suddenly replaced the old one
when they added my repo, but didn't support their existing databases.

However, it looks like rpm doesn't ignore Conflicts entries that are
conflicts-with-self. So after installation, yum complains:

** Found 6 pre-existing rpmdb problem(s), 'yum check' output follows:
...
postgresql-bdr94-9.4beta2-bdr0.7.1_1_2ndQuadrant.fc20.x86_64 has
installed conflicts postgresql94(x86-64): postgresql-bdr94-9.4beta2
...

This leaves me pretty stuck and I'm looking for ideas.

Is there any sane way to deal with this other than just rebuilding all
of upstream against my variant release?

Would you just omit the Conflicts entry and allow RPM to complain at
install time?


Rpm >= 4.9.0 allows self-conflicting packages to be installed, so if yum complains in such a situation that'd be a bug in yum. Yum check does not use rpm's dependency verification so it can disagree at times, this wouldn't be the first one.

	- Panu -

This variant package is a bit of a hack that's not going to have a long
life. It isn't a PostgreSQL fork; the changes in it will be merged back
into the next PostgreSQL release, at which point this one can go away.
The closest equivalent I can think of is a version of a package with a
bunch of improvements backported from a later release.


_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxxxxx
http://lists.rpm.org/mailman/listinfo/rpm-list




[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux