kumquat-buildroot/package/systemd/0001-install-don-t-use-ln-relative.patch

81 lines
2.6 KiB
Diff
Raw Normal View History

package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
From 006b1d65fd5ea6555fcb72054ecc20234f4175db Mon Sep 17 00:00:00 2001
From: Adam Duskett <aduskett@gmail.com>
Date: Sun, 31 Dec 2017 12:46:04 -0500
Subject: [PATCH] install: don't use ln --relative
Oldish enterprise-class distributions have too old versions of
coreutils, with ln not supporting --relative.
So we fake it.
ln --relative would create minimalist relative paths, but they are not
trivial to generate. Instead, we always create paths relative to the
root, i.e.:
ln -s --relative /usr/bin/foo /usr/sbin/foo
would create: /usr/sbin/foo -> ../bin/foo
while we do : /usr/sbin/foo -> ../../usr/bin/foo
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[aduskett@gmail.com: Added meson.build section and dirname wrapper in add-wants]
[aduskett@gmail.com: Update for systemd v237]
Signed-off-by: Adam Duskett <aduskett@gmail.com>
[tpiepho@impinj.com: Fix add-wants wrapper]
Signed-off-by: Trent Piepho <tpiepho@impinj.com>
---
meson.build | 2 +-
tools/meson-make-symlink.sh | 3 ++-
units/meson-add-wants.sh | 6 ++++--
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/meson.build b/meson.build
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
index e5ceb1e169..9d3c746da4 100644
--- a/meson.build
+++ b/meson.build
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
@@ -580,7 +580,7 @@ endforeach
conf.set_quoted('TELINIT', get_option('telinit-path'))
if run_command('ln', '--relative', '--help').returncode() != 0
- error('ln does not support --relative (added in coreutils 8.16)')
+ message('ln does not support --relative (added in coreutils 8.16)')
endif
############################################################
diff --git a/tools/meson-make-symlink.sh b/tools/meson-make-symlink.sh
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
index da0d13a341..4917eff7d1 100755
--- a/tools/meson-make-symlink.sh
+++ b/tools/meson-make-symlink.sh
@@ -8,5 +8,6 @@ mkdir -vp "$(dirname "${DESTDIR:-}$2")"
if [ "$(dirname $1)" = . ]; then
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
ln -vfs -T "$1" "${DESTDIR:-}$2"
else
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
- ln -vfs -T --relative "${DESTDIR:-}$1" "${DESTDIR:-}$2"
+ dds="$( dirname "$2" |sed -r -e 's:/+[^/]+:../:g; s:/$::' )"
+ ln -vfs -T "${dds}$1" "${DESTDIR:-}$2"
fi
diff --git a/units/meson-add-wants.sh b/units/meson-add-wants.sh
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
index a483d75b86..4642673d98 100755
--- a/units/meson-add-wants.sh
+++ b/units/meson-add-wants.sh
@@ -14,7 +14,7 @@ case "$target" in
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
;;
esac
-unitpath="${DESTDIR:-}${unitdir}/${unit}"
+unitpath="${unitdir}/${unit}"
case "$target" in
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
*/)
@@ -25,4 +25,6 @@ case "$target" in
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
;;
esac
-ln -vfs --relative "$unitpath" "$dir"
+[ ! -d "${dir}" ] && linkdir=`dirname "${dir}"` || linkdir="${dir}"
+dds="$(printf "%s" "${linkdir#${DESTDIR:-}}" |sed -r -e 's:/+[^/]+:../:g; s:/$::')"
+ln -vfs "$dds$unitpath" "$dir"
--
package/systemd: bump version to 243 Added config option for new systemd-pstore feature. Removed patches that have been committed upstream. Added symlinks required to enable some services. After extensive discussion with upstream it does not seem there is any acceptable option to have symlink installation handled on their side. The recommended solution from upstream is to have systemctl handle service installation, however this has a number of downsides such as requiring us to build a host-systemd just to install a few symlinks. Since we already customize service installation it is simpler for us to create the symlinks ourselves, this will also simplify service customization on our side as we will not need to disable any systemd default services in cases where we need to make customizations. In addition using systemctl would introduce a minimum host headers dependency in which we don't have the infrastructure to handle properly. The downside to this approach is that we need to track service creation changes from upstream ourselves, however this is relatively straightforward and since upstream service file locations are relatively stable regressions should be limited. This will mostly be a concern in regards to adding support for new systemd features. Details: https://github.com/systemd/systemd/issues/12767 https://github.com/systemd/systemd/pull/12164 https://github.com/systemd/systemd/pull/12769 https://github.com/systemd/systemd/pull/12775 Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Tested-by: Jérémy Rosen <jeremy.rosen@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-10-26 16:07:08 +02:00
2.20.1