[PATCH] RPM spec file with systemd integration
Hi All The attached patch provides an RPM spec file with systemd integration, rather than sysv init. I have tested it on Fedora 20 and 21. Note that this spec file includes: %global _hardened_build 1 Which automatically adds security hardening compiler flags. Thanks David
David, Why would you make a routing daemon dependent on a specific init system? James On Thu, Feb 26, 2015 at 2:34 PM, David Jorm <djorm@corp.iixpeering.net> wrote:
Hi All
The attached patch provides an RPM spec file with systemd integration, rather than sysv init. I have tested it on Fedora 20 and 21. Note that this spec file includes:
%global _hardened_build 1
Which automatically adds security hardening compiler flags.
Thanks David
Good question. My intention is not to make BIRD dependent on a specific init system, but to offer a choice. That is why my patch does not overwrite the existing bird.spec file, but instead provides a new bird-systemd.spec file as an alternative. I understand that systemd is controversial, and I do not agree with the model of "nuke sysv init and pave with systemd". I do, however, support choice. Thanks David On 02/27/2015 06:23 PM, james machado wrote:
David,
Why would you make a routing daemon dependent on a specific init system?
James
On Thu, Feb 26, 2015 at 2:34 PM, David Jorm <djorm@corp.iixpeering.net> wrote:
Hi All
The attached patch provides an RPM spec file with systemd integration, rather than sysv init. I have tested it on Fedora 20 and 21. Note that this spec file includes:
%global _hardened_build 1
Which automatically adds security hardening compiler flags.
Thanks David
On Fri, Feb 27, 2015 at 12:29 AM, David Jorm <djorm@corp.iixpeering.net> wrote:
Good question. My intention is not to make BIRD dependent on a specific init system, but to offer a choice. That is why my patch does not overwrite the existing bird.spec file, but instead provides a new bird-systemd.spec file as an alternative. I understand that systemd is controversial, and I do not agree with the model of "nuke sysv init and pave with systemd". I do, however, support choice.
Thanks David
I'm all for choice as well. Trying to take the controversy out of it, let me try to rephrase. What benefit(s) is/are gained by making BIRD dependent on systemd that is not available without the dependency? Conversely what breakage happens by making it a dependency? thanks, James
On 02/27/2015 06:23 PM, james machado wrote:
David,
Why would you make a routing daemon dependent on a specific init system?
James
On Thu, Feb 26, 2015 at 2:34 PM, David Jorm <djorm@corp.iixpeering.net> wrote:
Hi All
The attached patch provides an RPM spec file with systemd integration, rather than sysv init. I have tested it on Fedora 20 and 21. Note that this spec file includes:
%global _hardened_build 1
Which automatically adds security hardening compiler flags.
Thanks David
On 02/27/2015 06:39 PM, james machado wrote:
On Fri, Feb 27, 2015 at 12:29 AM, David Jorm <djorm@corp.iixpeering.net> wrote:
Good question. My intention is not to make BIRD dependent on a specific init system, but to offer a choice. That is why my patch does not overwrite the existing bird.spec file, but instead provides a new bird-systemd.spec file as an alternative. I understand that systemd is controversial, and I do not agree with the model of "nuke sysv init and pave with systemd". I do, however, support choice.
Thanks David
I'm all for choice as well. Trying to take the controversy out of it, let me try to rephrase. What benefit(s) is/are gained by making BIRD dependent on systemd that is not available without the dependency? Conversely what breakage happens by making it a dependency?
thanks, James
This patch would not make BIRD dependent on systemd, but would make it possible to build BIRD RPMs that are compatible with systemd. Fedora, CentOS, RHEL, OpenSUSE, and SLES account for the vast bulk of RPM-based Linux deployments. All of these distributions now use systemd. By providing a systemd spec file alongside the existing sysv init spec file, it would become possible for all of these distributions to make use of the official BIRD RPM packages. No breakage or regression would be introduced, as the existing sysv init spec file would remain available. Thanks David
Thanks for the enlightenment. James On Fri, Feb 27, 2015 at 1:13 AM, David Jorm <djorm@corp.iixpeering.net> wrote:
On 02/27/2015 06:39 PM, james machado wrote:
On Fri, Feb 27, 2015 at 12:29 AM, David Jorm <djorm@corp.iixpeering.net> wrote:
Good question. My intention is not to make BIRD dependent on a specific init system, but to offer a choice. That is why my patch does not overwrite the existing bird.spec file, but instead provides a new bird-systemd.spec file as an alternative. I understand that systemd is controversial, and I do not agree with the model of "nuke sysv init and pave with systemd". I do, however, support choice.
Thanks David
I'm all for choice as well. Trying to take the controversy out of it, let me try to rephrase. What benefit(s) is/are gained by making BIRD dependent on systemd that is not available without the dependency? Conversely what breakage happens by making it a dependency?
thanks, James
This patch would not make BIRD dependent on systemd, but would make it possible to build BIRD RPMs that are compatible with systemd. Fedora, CentOS, RHEL, OpenSUSE, and SLES account for the vast bulk of RPM-based Linux deployments. All of these distributions now use systemd. By providing a systemd spec file alongside the existing sysv init spec file, it would become possible for all of these distributions to make use of the official BIRD RPM packages. No breakage or regression would be introduced, as the existing sysv init spec file would remain available.
Thanks David
On 02/27/2015 08:34 AM, David Jorm wrote:
Hi All
The attached patch provides an RPM spec file with systemd integration, rather than sysv init. I have tested it on Fedora 20 and 21. Note that this spec file includes:
%global _hardened_build 1
Which automatically adds security hardening compiler flags.
Thanks David
Just following up - I think James' concerns were addressed, does anyone else have any concerns with this patch? If not, would any of the maintainers consider merging it? Thanks David
participants (2)
-
David Jorm -
james machado