Re: Unifying the spec files? - Mailing list pgsql-pkg-yum

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

On 07/30/2014 04:35 PM, Devrim Gündüz wrote:
> On Wed, 2014-07-30 at 13:37 +0800, Craig Ringer wrote:
>>
>> Take a look at the attached, which is a first cut unification
>> attempt. I'm going to do mock builds and test installs for each
>> arch now, but figured I'd send it for comment as well.
>
>
> Thanks ;) This is *really* great work!

Glad to hear it.

> # It should be supplied externally from mock/koju, rpmbuild
> macros, etc. s/koju/koji

Er. Rather.

> ============ $ rpm -qp --scripts
> postgresql94-server-9.4beta2-3PGDG.f20.x86_64.rpm |grep
> postgresql94 /bin/systemctl --no-reload disable
> postgresql94-9.4.service >/dev/null 2>&1 || : /bin/systemctl stop
> postgresql94-9.4.service >/dev/null 2>&1 || : /bin/systemctl
> try-restart postgresql94-9.4.service >/dev/null 2>&1 || :
>
> * Unit file name is postgresql-9.4.service. * I think using
> /usr/bin/systemctl would be much better. ============

I think both those were original, unless I mangled it when merging.
Will fix, anyway.

> ... series of other edits ...

No problem.

>> I've versioned the Provides:
>
> I am not whether this is right or not. OS-related packages may be
> broken, since we supply versioned Provides... Did you try
> installing libreoffice, for example?

I'll need to do more testing on this. It shouldn't be an issue;
unversioned Requires: will work as-is, at least, and versioned ones
that require >= should be fine.

I guess if someone Requires: postgresql = 9.3 it might be an issue.
I'll see if I can figure out how to query RPM's dependency graph so I
can see what people are declaring dependencies on.

>> I'd also like to parameterise the package basename
>> ("postgresql") to allow variants that still have "Provides:
>> postgresql" and "Provides: postgresql-%{majorversion}" but live
>> in a separate datadir. The immediate reason is to permit me to
>> package BDR, which is 9.4 but has a few catalog changes that mean
>> it can't run from a straight 9.4 datadir, without stomping on
>> PGDG packages and without the need to rebuild all the
>> dependencies. Thoughts?
>
> Can you please explain this more briefly?

Sure.

Sometimes I need to push a package containing a hotfix to someone
before it hits mainline and gets officially packaged and released in
the next point release, or need to supply a backported fix for a
version that's no longer under official support. That's not really any
fuss, as it's only minor changes and these sorts of things don't
affect the datadir format etc. So for things like this I just set the
Release: tag to reflect that it's a 2ndQuadrant package when I rebuild.

I'm in the process of prepping packages for BDR, and it's more
complicated there. BDR changes the catalog format to add support for
the sequence access method infrastructure that didn't make 9.4, so
while it's PostgreSQL 9.4 as far as the client libraries, protocol,
etc go the datadir format is _slightly_ different.

Because of that I'm not comfortable doing what I'd usually do and
rolling a "postgresql94-9.4beta2-1bdr" like I'd usually prepare a
"postgresql94-9.4beta2-1_2ndquadrant_lwlocks" or whatever. It's not
just a release of essentially the same code; it has a new extension
and enough core changes that it's not 100% on disk compatible.

So I'm trying to figure out how to do a release that doesn't create
problems and still inter-operates with all the existing packages in
yum.postgresql.org so it isn't necessary to rebuild and maintain
*everything*, especially as BDR is destined to merge back into core
over 9.5/9.6.

The libpq etc in BDR are totally compatible, it's only the
server/datadir that isn't. Some arguments are added to pg_dump and
pg_resetxlog, but nothing was removed/broken and no existing output
was changed. So, except for packaged backend extensions, it should be
fine to just install existing packages.

OTOH, it's also clearly wrong to permit an install of BDR to overwrite
a regular 9.4 install and attempt to use the same datadir.

So what I'm trying to do is find a way to produce packages that:

- - Meet Requires: for anyone who needs PostgreSQL clients, libs, etc

- - Use a different data directory

- - Conflict with the official upstream postgresql-server, or co-exist
  with it using different service/initscript names, etc.

and do so with minimal mess and confusion.


I'm thinking of giving it a different package name like
postgresql-bdr94 and adding lines like:

  Provides: postgresql94

for everything except postgresql-server, which won't provide
postgresql94-server and will conflict with it.

There are lots of assumptions burned into the package about the naming
of datadir, paths, etc, though, so I'm not sure how practical a new
top package name will be.

If I can make it work, I'd like to parameterise the top package name
in the specfile, so it can be easily overridden by releasers.



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

iQEcBAEBAgAGBQJT2LYCAAoJELBXNkqjr+S2sucIALVHT49XQjuz35EbbBDTqrEL
ux68PDjN9Hn8YltedA5z/pLABO4oh+JwjNkjOGVEV3y1mgXI2u4Rar0upp1rfsfI
QmbKPU/VXZT/IFcZbFtr7LorfDnaHS1Bsp9t1tEQSa7GcNsO3DqkqZTccUvlHxG1
0C3zYilgbYMOTCMxU+1Yvdodijh3NSJ2DEuFbaMz+/gOmJmWHTBLzXMCLn8sYZvW
9Twklog4EmGgP0/pIg9i3GoIJfPrsOiU7fN9rNxLfyzqDmPFV39Gznhd+71MNxJW
SoscQu/NtSl/82m3KP4/vcQpbmkrVI9MzJyCZ8s7HhOfq/brPvJXu1Cl3SvPBnk=
=/Kla
-----END PGP SIGNATURE-----