Distributing a partially-compatible variant package?

[Panu Matilainen]

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.
>