Hi,
I'm working on bringing pgpool-II packages (postgresql-pgpool-II-3.1.2-1) from Fedora over to RHEL6. I've already "hacked" Fedora version to play nice with RHEL (removing systemd references and supplanting systemd unit with init script). I have also conditionalized it to build either one depending on whether systemd is to be used or not using the
%if %{systemd_enabled} ... %else ... %endif
blocks. However I can't quite figure out an optimal way of determining which platform package is being compiled for (in other words: how to set up systemd_enabled macro automatically rather than rely on manual setup). I'm sure people on this list came across this problem more than once, and I would like to know what's the standard way of resolving it. What I'm trying to achieve is to get one SPEC for both Fedora and RHEL. Am I attacking this problem the wrong way?
On Thu, 02 Aug 2012 12:41:49 -0600 Dmitry Makovey dmitry@athabascau.ca wrote:
I'm working on bringing pgpool-II packages (postgresql-pgpool-II-3.1.2-1) from Fedora over to RHEL6. I've already "hacked" Fedora version to play nice with RHEL (removing systemd references and supplanting systemd unit with init script). I have also conditionalized it to build either one depending on whether systemd is to be used or not using the
%if %{systemd_enabled} ... %else ... %endif
blocks. However I can't quite figure out an optimal way of determining which platform package is being compiled for (in other words: how to set up systemd_enabled macro automatically rather than rely on manual setup). I'm sure people on this list came across this problem more than once, and I would like to know what's the standard way of resolving it. What I'm trying to achieve is to get one SPEC for both Fedora and RHEL. Am I attacking this problem the wrong way?
I don't think there's a standard for this, but an approach I've used with success is to test for the existence of the /run/lock directory:
# If directory /run/lock exists, do a systemd-based build; otherwise,a sysvinit-based build %global use_systemd %([ -d /run/lock ] && echo 1 || echo 0)
Cheers, Paul.
On August 2, 2012 20:12:10 Paul Howarth wrote:
I don't think there's a standard for this, but an approach I've used with success is to test for the existence of the /run/lock directory:
# If directory /run/lock exists, do a systemd-based build; otherwise,a sysvinit-based build %global use_systemd %([ -d /run/lock ] && echo 1 || echo 0)
That's a good idea, thanks Paul.
Being paranoid I'm thinking of adding a step:
%global use_systemd %([ -d /run/lock ] && rpm --quiet -qf /run/lock && echo 1 || echo 0)
that should make sure /run/lock is not there because it happened that sysadmin just decided create it manually and doesn't happen to run any systemd... Does that make sense?
On Thu, 02 Aug 2012 13:21:54 -0600 Dmitry Makovey dmitry@athabascau.ca wrote:
On August 2, 2012 20:12:10 Paul Howarth wrote:
I don't think there's a standard for this, but an approach I've used with success is to test for the existence of the /run/lock directory:
# If directory /run/lock exists, do a systemd-based build; otherwise,a sysvinit-based build %global use_systemd %([ -d /run/lock ] && echo 1 || echo 0)
That's a good idea, thanks Paul.
Being paranoid I'm thinking of adding a step:
%global use_systemd %([ -d /run/lock ] && rpm --quiet -qf /run/lock && echo 1 || echo 0)
that should make sure /run/lock is not there because it happened that sysadmin just decided create it manually and doesn't happen to run any systemd... Does that make sense?
Well it's fine in principle but unfortunately accessing the rpm database like that from within a package build is a bad idea because the build system may be using a chroot populated by a different version of rpm than the one the target system uses, which could make the rpm database unreadable at package build time, for instance if the builder and target systems use different versions of Berkeley DB.
The mock approach used in Fedora/EPEL is affected by this.
Paul.
On August 2, 2012 20:59:30 Paul Howarth wrote:
On Thu, 02 Aug 2012 13:21:54 -0600
Dmitry Makovey dmitry@athabascau.ca wrote:
On August 2, 2012 20:12:10 Paul Howarth wrote:
I don't think there's a standard for this, but an approach I've used with success is to test for the existence of the /run/lock directory:
# If directory /run/lock exists, do a systemd-based build; otherwise,a sysvinit-based build %global use_systemd %([ -d /run/lock ] && echo 1 || echo 0)
That's a good idea, thanks Paul.
Being paranoid I'm thinking of adding a step:
%global use_systemd %([ -d /run/lock ] && rpm --quiet -qf /run/lock && echo 1 || echo 0)
that should make sure /run/lock is not there because it happened that sysadmin just decided create it manually and doesn't happen to run any systemd... Does that make sense?
Well it's fine in principle but unfortunately accessing the rpm database like that from within a package build is a bad idea because the build system may be using a chroot populated by a different version of rpm than the one the target system uses, which could make the rpm database unreadable at package build time, for instance if the builder and target systems use different versions of Berkeley DB.
The mock approach used in Fedora/EPEL is affected by this.
ouch. good to know, thanks!
Paul.
On Thu, Aug 02, 2012 at 12:41:49PM -0600, Dmitry Makovey wrote:
I'm working on bringing pgpool-II packages (postgresql-pgpool-II-3.1.2-1) from Fedora over to RHEL6. I've already "hacked" Fedora version to play nice with RHEL (removing systemd references and supplanting systemd unit with init script). I have also conditionalized it to build either one depending on whether systemd is to be used or not using the
%if %{systemd_enabled} ... %else ... %endif
blocks. However I can't quite figure out an optimal way of determining which platform package is being compiled for (in other words: how to set up systemd_enabled macro automatically rather than rely on manual setup). I'm sure people on this list came across this problem more than once, and I would like to know what's the standard way of resolving it. What I'm trying to achieve is to get one SPEC for both Fedora and RHEL. Am I attacking this problem the wrong way?
I would suggest to do it the following way:
%if 0%{?rhel} && 0%{?rhel} <= 6 %define systemd_enabled 0 %else %define systemd_enabled 1 %endif
This is the way I do it in my backports (e.g. PostgreSQL 9.x for RHEL 6.x).
On August 2, 2012 23:36:25 Jos Vos wrote:
I would suggest to do it the following way:
%if 0%{?rhel} && 0%{?rhel} <= 6 %define systemd_enabled 0 %else %define systemd_enabled 1 %endif
This is the way I do it in my backports (e.g. PostgreSQL 9.x for RHEL 6.x).
I just applied above and it works exactly as needed, so I'm going to stick with that for now due to it's simplicity :) Thanks.
epel-devel@lists.fedoraproject.org
-
Dmitry Makovey -
Jos Vos -
Paul Howarth