Thread: New repmgr packages

Hi all,

I was working on repmgr-2.0 packages to update some systems (but with
CFLAGS we need) and just saw that there's a new 2.0 repmgr package
(thumbs up for that).

I did find a few things which I corrected differently from the way it
was on the .src.rpm, basically I removed the makefile patch and set
the PATHs accordingly in the spec file.

Another thing missing is the PGDG tag in Release.

I also saw some dependencies which were there before, but aren't
anymore (rsync for example, and also openssh (which was mistakenly
openssl before))

I'm sending a patch for repmgr.spec with what I'm pointing out here.

I also changed a few things to make it look more like the
postgresql-X.Y.spec files.

Cheers,

--
Martín Marqués http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Hi,

On Thu, 2014-03-20 at 17:30 -0300, Martín Marqués wrote:

> I was working on repmgr-2.0 packages to update some systems (but with
> CFLAGS we need) and just saw that there's a new 2.0 repmgr package
> (thumbs up for that).

Yeah, I built them while working on new releases :)

> I did find a few things which I corrected differently from the way it
> was on the .src.rpm, basically I removed the makefile patch and set
> the PATHs accordingly in the spec file.

Err, IIRC, we *should not* export PATH in the spec file, per packaging
guidelines. That is why I add patches to each RPM.

> Another thing missing is the PGDG tag in Release.

We add PGDG only to PostgreSQL itself. The rest does not belong to PGDG,
so...

> I also saw some dependencies which were there before, but aren't
> anymore (rsync for example, and also openssh (which was mistakenly
> openssl before))

Ah.. Good catch. Created #164 for this:
http://wiki.pgrpms.org/ticket/164


> I'm sending a patch for repmgr.spec with what I'm pointing out here.
>
> I also changed a few things to make it look more like the
> postgresql-X.Y.spec files.

Do you mean these?

-%global pgmajorversion 91
-%global pginstdir /usr/pgsql-9.1
+%global pgmajorversion 9.1
+%define pgpackageversion 91
+%global pginstdir /usr/pgsql-%{pgmajorversion}

If so, our version is exactly the same as in the other packages. We
don't have pgpackageversion parameter anywhere. Am I missing something?

Thanks!

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

El 20/03/14 17:40, Devrim GÜNDÜZ escribió:
>
>> I did find a few things which I corrected differently from the
>> way it was on the .src.rpm, basically I removed the makefile
>> patch and set the PATHs accordingly in the spec file.
>
> Err, IIRC, we *should not* export PATH in the spec file, per
> packaging guidelines. That is why I add patches to each RPM.

I can't find anything about *not* exporting PATH in the packaging
guidelines (nor else where). Maybe you refer to export LD_LIBRARY_PATH?

In any case, I dislike both procedures.

Maybe the best way (and the more sane way) is to use alternatives to
have pg_config, and other postgres binaries that don't have
alternatives (I remember pg_controldata ATM) in the path? But that
should go to the postgres packages.

>> Another thing missing is the PGDG tag in Release.
>
> We add PGDG only to PostgreSQL itself. The rest does not belong to
> PGDG, so...

OK. I thought that the PDGD tag was related to who was distributing
the packages, that's why I thought it should be there as well. No problem.

>> I also saw some dependencies which were there before, but aren't
>>  anymore (rsync for example, and also openssh (which was
>> mistakenly openssl before))
>
> Ah.. Good catch. Created #164 for this:
> http://wiki.pgrpms.org/ticket/164

Thanks. Will follow from there.

>> I'm sending a patch for repmgr.spec with what I'm pointing out
>> here.
>>
>> I also changed a few things to make it look more like the
>> postgresql-X.Y.spec files.
>
> Do you mean these?
>
> -%global pgmajorversion 91 -%global pginstdir /usr/pgsql-9.1
> +%global pgmajorversion 9.1 +%define pgpackageversion 91 +%global
> pginstdir /usr/pgsql-%{pgmajorversion}
>
> If so, our version is exactly the same as in the other packages. We
> don't have pgpackageversion parameter anywhere. Am I missing
> something?

Maybe I am! ;)

I thought of splitting them in majorverion and packageversion, but
related to the postgres installation, so we can have, in the example
from above, 91 to use in the BuildRequires and Requires, and a 9.1 to
use in the pginstdir. Else you end up hardcoding them (or at least one
of them like it is now).

Now, I started thinking of something that maybe Christian or Jaime can
answer which is not related to packaging (at least not directly) but
has big influence in it: Do we need different repmgr compilations for
the different versions of PostgreSQL?

Cheers,

- --
Martín Marqués                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/

iQEcBAEBAgAGBQJTK2L4AAoJEHsDtEgBAFTSw/MH/0uALSsEFJY7QymdB9xAbNG6
UhZt1grWsDBmdW+0diKuLO5Vg2CfPFUY9+mtqbgXyOGpTmD0t6Ul3e6JtXh9cvh1
laDFmzjASc81hnLrV62fsPNLkX1bUp8gpYtxlk02wtxWlK4fQeU/Tf94AFuf01pP
ShoAfNLtmq5k+9qxMKpo0YHAOHM5jlyjD+Nmagja85Zn4Ejo6x+8/TGQbraMSOC5
fHjtvbIrvSDxbXNF/sbrN76qnIDngf07a4u6ec1dg0YpAS0bPF3Zq165szsMVgo7
7Id6ChgTeocKHRbtWLnAQOQszUQ/L6wZ7m8I9tVfjYziF3e7QUJX3Zt0foEAPW4=
=NpaQ
-----END PGP SIGNATURE-----

Hi,

On 20/03/14 18:51, Martín Marqués wrote:
> Now, I started thinking of something that maybe Christian or Jaime can
> answer which is not related to packaging (at least not directly) but
> has big influence in it: Do we need different repmgr compilations for
> the different versions of PostgreSQL?

This is a good question.

After checking it three times it should be safe doing that. We're only
using some version-dependent macros which get resolved by
compile-time, and the changes on that macros are backwards-compatible.

That said I have to admit that I didn't test it. Before doing so I
would definitely want to test it.

Best regards,

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

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

El 21/03/14 04:39, Christian Kruse escribió:
> Hi,
>
> On 20/03/14 18:51, Martín Marqués wrote:
>> Now, I started thinking of something that maybe Christian or
>> Jaime can answer which is not related to packaging (at least not
>> directly) but has big influence in it: Do we need different
>> repmgr compilations for the different versions of PostgreSQL?
>
> This is a good question.
>
> After checking it three times it should be safe doing that. We're
> only using some version-dependent macros which get resolved by
> compile-time, and the changes on that macros are
> backwards-compatible.
>
> That said I have to admit that I didn't test it. Before doing so I
> would definitely want to test it.

Well, in any case, we need to have -devel package installed, and
AFAICS the packages are compiled for each version of PG, or at least
there is a mention of the PG version to use for checking on include
files (check for the -devel package to be installed) and the bindir.

On debian's repmgr package from pgdg, binaries go to /usr/bin/, but on
RHEL they go with the binaries of the version they were compiled
against, i.e. /usr/pgsql-9.3/bin/ for 9.3. If they are compatible, we
could just make 1 package for any version on PG.

Also checking through both packaging, I think we should add some
examples (repmgr.conf.sample) to the rpm. Does are sometimes very
valuable.

P.D.: Will send comments and files on another reply.

Regards,

- --
Martín Marqués                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/

iQEcBAEBAgAGBQJTMemnAAoJEHsDtEgBAFTSLEMH/0e6aAkYfIl/9gm+sxtPSDoj
8MrjMR61Dz4u2kJ9dNNh/pGtb8HrAAlwV26cgXrYdt5GejYxLC6FSAeWtjpETPsH
y2KwvE8du6yUVIjUNn+xfFQOX0NavOLPh/89hoZt/r1gpJHC3pLiCRzMTbwPodhn
d4QxjBeQT+YZjWdrBw/6+yQSx9nQeZCCNZkbmcDpq4UDGRJK4iBz0HqWI1vDVKI0
ZTlAqz5Gcn0J2v2ztvCO539OAkGQYyMfQ9i8hmzfQQKS1m/9CN/92cqnTOAqJ6Gp
QJsvk3F8OfUSH4Ow6AZ+7muvH3Rnbx1k94N9LQWKWQD8vYVAWLeFIpajkHXNt3k=
=RXQa
-----END PGP SIGNATURE-----

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

El 20/03/14 17:40, Devrim GÜNDÜZ escribió:
>
>> Another thing missing is the PGDG tag in Release.
>
> We add PGDG only to PostgreSQL itself. The rest does not belong to
> PGDG, so...

I'm not very involved on this and I might be missing some piece of
information, but why does the the Debian packages have the pgdg tag on
the name while the RHEL don't?

I personally think that we have to differentiate pgdg packages from
others. Unless this is not at all pgdg, but a personal package from
Devrim, which is also cool, but when multiple packages for the same
source come up, there has to be a way to discriminate one from the other.

>> I also saw some dependencies which were there before, but aren't
>> anymore (rsync for example, and also openssh (which was
>> mistakenly openssl before))
>
> Ah.. Good catch. Created #164 for this:
> http://wiki.pgrpms.org/ticket/164

To be more accurate, we need these dependencies:

BuildRequires:  postgresql%{pgpackageversion}-devel libxslt-devel
openssl-devel
Requires:       postgresql%{pgpackageversion}-server libxslt openssh rsync

There was a missing "-devel" in the postgres package in the BuildRequires.

>> I'm sending a patch for repmgr.spec with what I'm pointing out
>> here.
>>
>> I also changed a few things to make it look more like the
>> postgresql-X.Y.spec files.
>
> Do you mean these?
>
> -%global pgmajorversion 91 -%global pginstdir /usr/pgsql-9.1
> +%global pgmajorversion 9.1 +%define pgpackageversion 91 +%global
> pginstdir /usr/pgsql-%{pgmajorversion}
>
> If so, our version is exactly the same as in the other packages.
> We don't have pgpackageversion parameter anywhere. Am I missing
> something?

It makes it easier to define paths and so later, but....

But now that I think about it, and also talking to some of the
packagers from Debian, we could just build one repmgr and place the
binaries in /usr/bin/ (which is what Debian does).

This would reduce tremendously things related to different versions of
PostgreSQL in the spec file.

Thoughts?

Regards,

- --
Martín Marqués                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/

iQEcBAEBAgAGBQJTMe8mAAoJEHsDtEgBAFTSm3kH/At3BXlOLJtorjtO1cYJUizq
qaX0duJXY11NIQYtoZQPXJYz1cOPB0oGAUj49hnqjJNZJzlCpRKJObZ4PnJbsqfj
MKNygIsgPzJ2b3TkaefyxAcG3TtZ2z+C8BoerBm8g+S2wnhgYpUe9zgZzUS0GHTM
5SkpnqbyofQik9Ge2+eaTGMeWrb/737xdN+McsFqQsaWWVRRLPWU9huWh6zXfsHg
1SlLiS78z56x2gB5ZSf3A01DUjwGNuW0ITjF6qkqber2C7BSfw83BViYCf8QViiT
CWjbeBltGjvHFzKU2FFbqUC4C5U9x61T6zAEppV9O/MLhi0OdCaLTPE0Qb90agA=
=OjnE
-----END PGP SIGNATURE-----

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

Ups, forgot to send these files I made last week.

repmgr.init is the init file, and repmgr.sysconfig is the sysconfig file.

Add the Sources:

Source1:        repmgrd.init
Source2:        repmgrd.sysconfig

Lines added to %install are:

# Install init script
install -p -d %{buildroot}%{_initrddir}
install -p -m 755 %{SOURCE1} %{buildroot}%{_initrddir}/repmgrd
# Install conf file
install -p -d %{buildroot}%{_sysconfdir}/sysconfig
install -p -m 644 %{SOURCE2} %{buildroot}%{_sysconfdir}/sysconfig/repmgrd

I've tested them and they work great, as long as you configure
/etc/sysconfig/repmgrd first.

Regards,

- --
Martín Marqués                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/

iQEcBAEBAgAGBQJTMfi1AAoJEHsDtEgBAFTSAy4H/jJc8gGdm6pFo8Arev1pEGNy
mtQQ2kviGOXm48BKMKS1R+PzFvuPhY64wOo/3rQAQyr/8UlyzyBcTeIAU/cW0dWF
9tR2+scHnhTfRu0PQi3jqkuGlU2rki52WCR0Vx66Zy73FbkC05j31CtaG3VE8bS7
jAa66qBNBYv7dT+ZORHMRQh4+1HKFl0yviFRXI6/vIHySOMLv94OSNX8hZZdUZ3F
xLqCvgywe/FvGxUfTCTNh0jHvIGFMsBt71eukxPCUQtVQik1hLeS3on9enmIxp92
j0YsRGrKZLEX6VFzTHjjJTRuH90fDHIlk0qlgcRbcF10MxT6ZQiJdC+XcfHA0Yo=
=iPZW
-----END PGP SIGNATURE-----

Hi,

On Thu, 2014-03-20 at 18:51 -0300, Martín Marqués wrote:
> >
> > Err, IIRC, we *should not* export PATH in the spec file, per
> > packaging guidelines. That is why I add patches to each RPM.
>
> I can't find anything about *not* exporting PATH in the packaging
> guidelines (nor else where). Maybe you refer to export LD_LIBRARY_PATH?

It should be in the Fedora's packaging guidelines.

> In any case, I dislike both procedures.

Feel free to complain to Fedora. The policy has always been being close
to Fedora guidelines.

> Maybe the best way (and the more sane way) is to use alternatives to
> have pg_config, and other postgres binaries that don't have
> alternatives (I remember pg_controldata ATM) in the path? But that
> should go to the postgres packages.

That is never going to happen, too. We add alternatives to binaries that
are multi version compliant only. pg_config is not one of those.

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 Fri, 2014-03-21 at 08:39 +0100, Christian Kruse wrote:

> After checking it three times it should be safe doing that. We're only
> using some version-dependent macros which get resolved by
> compile-time, and the changes on that macros are backwards-compatible.
>
> That said I have to admit that I didn't test it. Before doing so I
> would definitely want to test it.

Are we talking about separate repmgr packages for 9.3, 9.2, 9.1 and so?
If yes, I can do it along with new releases. Did you find time to look
at it?

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 Tue, 2014-03-25 at 17:40 -0300, Martín Marqués wrote:

> Also checking through both packaging, I think we should add some
> examples (repmgr.conf.sample) to the rpm. Does are sometimes very
> valuable.

Good idea. I would like repmgr to install this sample file by make
install though, That way, RPMs will pick them up automagically.

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 02.04.2014 14:35, Devrim GÜNDÜZ wrote:
> On Fri, 2014-03-21 at 08:39 +0100, Christian Kruse wrote:
>> That said I have to admit that I didn't test it. Before doing so I
>> would definitely want to test it.
>
> Are we talking about separate repmgr packages for 9.3, 9.2, 9.1 and so?

No, we've been talking for one repmgr package for all versions.

> If yes, I can do it along with new releases.

That would really be a better solution. This gives us the freedom to
make version-specific changes and to depend to version-specific
changes in PostgreSQL.

> Did you find time to look at it?

No. I've been waiting for a comment on that :)

Best regards,

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

Hi,

On Tue, 2014-03-25 at 18:03 -0300, Martín Marqués wrote:

> I'm not very involved on this and I might be missing some piece of
> information, but why does the the Debian packages have the pgdg tag on
> the name while the RHEL don't?

I don't know why Debian folks use it, but RPMs have never did it this
way. I personally would like to omit using PGDG for the software that is
not being developed by them.

> I personally think that we have to differentiate pgdg packages from
> others. Unless this is not at all pgdg, but a personal package from
> Devrim, which is also cool, but when multiple packages for the same
> source come up, there has to be a way to discriminate one from the
> other.

Well, none of these packages are Devrim's packages. These packages are
distributed through the official RPM repo, and I am not the only
maintainer right now.

Also, they are not PGDG, either, per above.

Which multiple packages are we talking about, BTW?


> But now that I think about it, and also talking to some of the
> packagers from Debian, we could just build one repmgr and place the
> binaries in /usr/bin/ (which is what Debian does).
>
> This would reduce tremendously things related to different versions of
> PostgreSQL in the spec file.
>
> Thoughts?

Debian packaging and our packaging are not identical to each other.
Also, if you look at the spec file, it is the repmgr that installs
itself under PostgreSQL binary directory. It uses PGXS for that.

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-04-02 at 14:38 +0200, Christian Kruse wrote:

> > If yes, I can do it along with new releases.
>
> That would really be a better solution. This gives us the freedom to
> make version-specific changes and to depend to version-specific
> changes in PostgreSQL.

Ok. Let me do this, and incorporate Martín's changes to spec file, while
working on this.

> > Did you find time to look at it?
>
> No. I've been waiting for a comment on that :)

Let me provide you an SRPM first, so that you can test. How does it
sound?

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 Tue, 2014-03-25 at 18:44 -0300, Martín Marqués wrote:
> Ups, forgot to send these files I made last week.
>
> repmgr.init is the init file, and repmgr.sysconfig is the sysconfig file.

Thanks. What about Fedora 18+, and RHEL 7? Can you provide a unit file,
or do you want me to do it? (I can do, if you want)

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 02.04.2014 14:53, Devrim GÜNDÜZ wrote:
>>> Did you find time to look at it?
>>
>> No. I've been waiting for a comment on that :)
>
> Let me provide you an SRPM first, so that you can test. How does it
> sound?

What do you expect me to test? I thought you're going to generate
alternative packages for different PostgreSQL versions?

Tests would've been necessary if you compile repmgr against e.g. 9.3
and run it for 9.0 or something like that since macros and data types
in PostgreSQL we use in repmgr changed.

Best regards,

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

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

El 02/04/14 09:55, Devrim GÜNDÜZ escribió:
>
> Hi,
>
> On Tue, 2014-03-25 at 18:44 -0300, Martín Marqués wrote:
>> Ups, forgot to send these files I made last week.
>>
>> repmgr.init is the init file, and repmgr.sysconfig is the
>> sysconfig file.
>
> Thanks. What about Fedora 18+, and RHEL 7? Can you provide a unit
> file, or do you want me to do it? (I can do, if you want)

I don't have a el7 machine now. I do have FC19/20 to check.

The only thing there to change AFAICS is that instead of SysV init
scripts, we have to provide Systemd.

Is that all?

I can check on that later today.

- --
Martín Marqués                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/

iQEcBAEBAgAGBQJTPCPRAAoJEHsDtEgBAFTSWd0H+wcxUeTZQfS66Vjv3QC9qQOj
vVge4Tu2ibD6/pl6d5igu7f+u8I4sn0au0QoA9riVJcGZmnhF4Gu/RIZs//5buS1
Yi9T26C/ywxD1n6GfJ9Runtux8+RUFsXu12p6yuuwAGqvi44/RubHxu1p8oAnKEA
zp5kEosNaT1oVyrVmuOgd5LBhR1wNv4CS/TDQ9dm2AJemT68KZqdXjDO99BNudUz
uOjE4iHUGYdCv9Y2Njhgo80LBvNow5KHhQ7btPRYUdxhdr9uh/UPy8lW51s6lR6w
ojKZeRUC9Nx/khrz+EBonuGtay83gHu06iPNTGUAxj2/cN8ZefwR2evW2sjsZ9c=
=eHnR
-----END PGP SIGNATURE-----

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

El 02/04/14 10:24, Christian Kruse escribió:
> Hi,
>
> On 02.04.2014 14:53, Devrim GÜNDÜZ wrote:
>>>> Did you find time to look at it?
>>>
>>> No. I've been waiting for a comment on that :)
>>
>> Let me provide you an SRPM first, so that you can test. How does
>> it sound?
>
> What do you expect me to test? I thought you're going to generate
> alternative packages for different PostgreSQL versions?
>
> Tests would've been necessary if you compile repmgr against e.g.
> 9.3 and run it for 9.0 or something like that since macros and data
> types in PostgreSQL we use in repmgr changed.

The problem I see is that different versions of repmgr are made for
different versions of Postgres, or are they the same binaries just
placing the repmgr and repmgrd bins in different paths?

It ends up being annoying when you have more then one version of PG
installed (or at least more then one version of pgdg repository
configured), else, it's straight forward.

- --
Martín Marqués                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/

iQEcBAEBAgAGBQJTPCS8AAoJEHsDtEgBAFTSypsH/j0wlWPM49mCex964HNq5PYd
jGaIvJ9Tv9dpaoxWZ3bqpHhGEGASP/xqbSuDBJ+sElrcYbUkCOXG+NcoVz9iclnr
eFBa1aNaHOwThVEKEecPACRGeyIpX6157nHrE3650mXue1mIUDpLJYMqWWpJyE47
w7WoaVDjUxygJ/efPOYVjkRNyZAiPYlykwfrJuZcDHmoj+X0eQClljg0A5wYV87/
5vEVLT9NvU+DdBr/wLZDOOqvvVQPzzLp4PYr/OVZDcEb9/XZnQKWltwFsjVgKxJe
wf31k+t2K5hxU/DTj0Kk2SqGMtm9R5jW9yum2xXSlHVDuTcPs2kalrarzuqzT+E=
=uMnC
-----END PGP SIGNATURE-----

Re: Devrim GÜNDÜZ 2014-04-02 <1396442683.3559.20.camel@asus02-laptop04.gunduz.org>
>
> Hi,
>
> On Tue, 2014-03-25 at 18:03 -0300, Martín Marqués wrote:
>
> > I'm not very involved on this and I might be missing some piece of
> > information, but why does the the Debian packages have the pgdg tag on
> > the name while the RHEL don't?
>
> I don't know why Debian folks use it, but RPMs have never did it this
> way. I personally would like to omit using PGDG for the software that is
> not being developed by them.

The packages in the apt.postgresql.org repository have "pgdg" in the
version number because the repo is operated by PostgreSQL. That's to
make clear where the packages where built.

The version number from the original Debian package is suffixed with
.pgdgNN+1, where NN is the Debian or Ubuntu version they target.

Christoph
--
cb@df7cb.de | http://www.df7cb.de/

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

El 02/04/14 09:44, Devrim GÜNDÜZ escribió:
>
>> But now that I think about it, and also talking to some of the
>> packagers from Debian, we could just build one repmgr and place
>> the binaries in /usr/bin/ (which is what Debian does).
>>
>> This would reduce tremendously things related to different
>> versions of PostgreSQL in the spec file.
>>
>> Thoughts?
>
> Debian packaging and our packaging are not identical to each
> other. Also, if you look at the spec file, it is the repmgr that
> installs itself under PostgreSQL binary directory. It uses PGXS for
> that.

I was thinking about Fedora packaging rules, but now I see that if
repmgr is compiled against the Fedora postgresql packages, it will get
installed with all the other binaries in /usr/bin/.

P.D.: I'm going to test a compilation/installation against F19/F20.

Regards,

- --
Martín Marqués                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/

iQEcBAEBAgAGBQJTPEJDAAoJEHsDtEgBAFTSkPEIAI/pawjskHlpTayxS98WVs01
fnFXLSx454zMVXy4dWaKQ+vw9d3/eAgyJ6rvkWak5bniXt2WW2KzO2Gwz9fTjZhe
Qdbhg2N+yMyIFnnMAhzH8RkgLfhHzMMkj8SZgfSoKi4B6rIBArlcZm/G+DNN0hH+
64aSW42X8rvfUv9qVrQIqrDTAj7s47LrWi588m4p5M2DXDbsUYGlWY2/b5XbA+LG
x+xSGzfXSjQjqlAb0LTHe6+fff1JSfxIh0Qf+JNtv5JZCtZ122J9wFa50VbVk0Tq
3dEb7/Dh1l17O39+Sbpe3glcqxHp76kXOyCLfhwoGRbx4lHSwRWb2cekG/yYGTg=
=CVp9
-----END PGP SIGNATURE-----