When using the same policy on several hosts with different Linux distributions
the DISTRO variable can't be defined in the build.conf of the build directory
because this file is tracked with git.
Instead of maintaining a local patch per host to define DISTRO in build.conf
or of building using "make DISTRO=...", this commit introduces a DISTRO_DETECT
boolean in build.conf which automatically fills DISTRO with the name of the
distro of the building host.
DISTRO_DETECT definition is not copied in the installed build.conf file
(/usr/share/selinux/refpolicy/include/build.conf) because this file would have
the DISTRO variable set.
---
Makefile | 6 ++++++
build.conf | 3 +++
support/detect_distro.sh | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 51 insertions(+)
create mode 100644 support/detect_distro.sh
diff --git a/Makefile b/Makefile
index 45bd45d..3926cd5 100644
--- a/Makefile
+++ b/Makefile
@@ -181,6 +181,12 @@ ifeq "$(TYPE)" "mcs"
endif
# enable distribution-specific policy
+ifeq "$(DISTRO_DETECT)" "y"
+ ifeq "$(DISTRO)" ""
+ DISTRO := $(shell $(SHELL) $(support)/detect_distro.sh)
+ endif
+endif
+
ifneq ($(DISTRO),)
M4PARAM += -D distro_$(DISTRO)
endif
diff --git a/build.conf b/build.conf
index 5a521c4..c00e4b0 100644
--- a/build.conf
+++ b/build.conf
@@ -29,6 +29,9 @@ NAME = refpolicy
# Fedora users should enable redhat.
#DISTRO = redhat
+# Detect distribution at build time if DISTRO is empty
+DISTRO_DETECT = y
+
# Unknown Permissions Handling
# The behavior for handling permissions defined in the
# kernel but missing from the policy. The permissions
diff --git a/support/detect_distro.sh b/support/detect_distro.sh
new file mode 100644
index 0000000..d0b4948
--- /dev/null
+++ b/support/detect_distro.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+# Detect which Linux distribution is running
+
+# Only Linux is supported
+[ "$(uname -s)" = "Linux" ] || exit
+
+# Use LSB release
+LSB_ID=$(lsb_release --id --short 2> /dev/null)
+if [ -n "$LSB_ID" ]
+then
+ echo "$LSB_ID" | tr '[A-Z]' '[a-z]'
+ exit
+fi
+
+# Use OS release
+if [ -r /etc/os-release ]
+then
+ OS_ID=$(sed -n 's/^ID\s*=\s*\(.*\)$/\1/p' /etc/os-release)
+ if [ -n "$OS_ID" ]
+ then
+ echo "$OS_ID"
+ exit
+ fi
+fi
+
+# Use files
+if [ -r /etc/arch-release ]
+then
+ echo "arch"
+elif [ -r /etc/debian_version ]
+then
+ echo "debian"
+elif [ -r /etc/gentoo-release ]
+then
+ echo "gentoo"
+elif [ -r /etc/redhat-release ]
+then
+ echo "redhat"
+elif [ -r /etc/SuSE-release ]
+then
+ echo "suse"
+fi
--
1.8.5.4
On 2/18/2014 6:20 PM, Nicolas Iooss wrote:
> When using the same policy on several hosts with different Linux distributions
> the DISTRO variable can't be defined in the build.conf of the build directory
> because this file is tracked with git.
>
> Instead of maintaining a local patch per host to define DISTRO in build.conf
> or of building using "make DISTRO=...", this commit introduces a DISTRO_DETECT
> boolean in build.conf which automatically fills DISTRO with the name of the
> distro of the building host.
>
> DISTRO_DETECT definition is not copied in the installed build.conf file
> (/usr/share/selinux/refpolicy/include/build.conf) because this file would have
> the DISTRO variable set.
I'm reluctant to add this, as the refpolicy build system is already more complicated than I'd like. I also feel that the use case is too uncommon.
I suggest that for your scenario that you instead have a local build.conf that is included by the revision-controlled build.conf. Then in the local one you can set DISTRO without putting it on the make command.
> ---
> Makefile | 6 ++++++
> build.conf | 3 +++
> support/detect_distro.sh | 42 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 51 insertions(+)
> create mode 100644 support/detect_distro.sh
>
> diff --git a/Makefile b/Makefile
> index 45bd45d..3926cd5 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -181,6 +181,12 @@ ifeq "$(TYPE)" "mcs"
> endif
>
> # enable distribution-specific policy
> +ifeq "$(DISTRO_DETECT)" "y"
> + ifeq "$(DISTRO)" ""
> + DISTRO := $(shell $(SHELL) $(support)/detect_distro.sh)
> + endif
> +endif
> +
> ifneq ($(DISTRO),)
> M4PARAM += -D distro_$(DISTRO)
> endif
> diff --git a/build.conf b/build.conf
> index 5a521c4..c00e4b0 100644
> --- a/build.conf
> +++ b/build.conf
> @@ -29,6 +29,9 @@ NAME = refpolicy
> # Fedora users should enable redhat.
> #DISTRO = redhat
>
> +# Detect distribution at build time if DISTRO is empty
> +DISTRO_DETECT = y
> +
> # Unknown Permissions Handling
> # The behavior for handling permissions defined in the
> # kernel but missing from the policy. The permissions
> diff --git a/support/detect_distro.sh b/support/detect_distro.sh
> new file mode 100644
> index 0000000..d0b4948
> --- /dev/null
> +++ b/support/detect_distro.sh
> @@ -0,0 +1,42 @@
> +#!/bin/sh
> +# Detect which Linux distribution is running
> +
> +# Only Linux is supported
> +[ "$(uname -s)" = "Linux" ] || exit
> +
> +# Use LSB release
> +LSB_ID=$(lsb_release --id --short 2> /dev/null)
> +if [ -n "$LSB_ID" ]
> +then
> + echo "$LSB_ID" | tr '[A-Z]' '[a-z]'
> + exit
> +fi
> +
> +# Use OS release
> +if [ -r /etc/os-release ]
> +then
> + OS_ID=$(sed -n 's/^ID\s*=\s*\(.*\)$/\1/p' /etc/os-release)
> + if [ -n "$OS_ID" ]
> + then
> + echo "$OS_ID"
> + exit
> + fi
> +fi
> +
> +# Use files
> +if [ -r /etc/arch-release ]
> +then
> + echo "arch"
> +elif [ -r /etc/debian_version ]
> +then
> + echo "debian"
> +elif [ -r /etc/gentoo-release ]
> +then
> + echo "gentoo"
> +elif [ -r /etc/redhat-release ]
> +then
> + echo "redhat"
> +elif [ -r /etc/SuSE-release ]
> +then
> + echo "suse"
> +fi
>
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
2014-03-03 15:39 GMT+01:00 Christopher J. PeBenito <[email protected]>:
> On 2/18/2014 6:20 PM, Nicolas Iooss wrote:
> > When using the same policy on several hosts with different Linux
> distributions
> > the DISTRO variable can't be defined in the build.conf of the build
> directory
> > because this file is tracked with git.
> >
> > Instead of maintaining a local patch per host to define DISTRO in
> build.conf
> > or of building using "make DISTRO=...", this commit introduces a
> DISTRO_DETECT
> > boolean in build.conf which automatically fills DISTRO with the name of
> the
> > distro of the building host.
> >
> > DISTRO_DETECT definition is not copied in the installed build.conf file
> > (/usr/share/selinux/refpolicy/include/build.conf) because this file
> would have
> > the DISTRO variable set.
>
> I'm reluctant to add this, as the refpolicy build system is already more
> complicated than I'd like. I also feel that the use case is too uncommon.
>
> I suggest that for your scenario that you instead have a local build.conf
> that is included by the revision-controlled build.conf. Then in the local
> one you can set DISTRO without putting it on the make command.
>
> Thanks for your suggestion. I've added "-include build-local.conf" to my
build.conf so that it automatically includes the host-specific build.conf
if it exists. By doing so, "make" works as expected but I'm wondering
whether some obscure program used in the build system of the policy may
expect build.conf to only have comments and variable definitions. If that's
the case, I'll change my Makefile instead of build.conf (and I'll never
upstream this change).
While speaking about files which aren't revision-controlled, if I send a
patch which creates a .gitignore file which contains most of the lines of
http://oss.tresys.com/projects/refpolicy/browser/.gitignore?rev=190b058eaef2551f9045121f9f2e558b901ff733,
will it have any chance of being accepted?
By the way, I'm trying to get SELinux work on Archlinux, and that's why I'm
in an uncommon scenario of using the same policy with Arch and Debian.
Right now, the SELinux-configured Archlinux packages are working quite well
but my policy is already some patches away from the refpolicy (with some
patches for systemd, others to handle all binaries in /usr/bin...). I've
experienced a bunch of issues that were solved with patches which can't be
upstreamed "as-is" and that's why I'm looking forward to the support of
systemd in the reference policy.
Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20140304/cae66794/attachment.html
On 03/03/2014 06:00 PM, Nicolas Iooss wrote:
> While speaking about files which aren't revision-controlled, if I send a patch which creates a .gitignore file which contains most of the lines of http://oss.tresys.com/projects/refpolicy/browser/.gitignore?rev=190b058eaef2551f9045121f9f2e558b901ff733, will it have any chance of being accepted?
Yes, that would be fine.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com