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
