rpm-build/scripts/symlinks.req.files
Alexey Tourbin 9693c85f52 implemented symlinks.req
Consider R-devel package, which has its own private bin/ directory,
where it keeps certain scripts.

$ rpm -ql R-devel |grep libtool
/usr/lib/R/bin/libtool
$ rpm -ql R-devel |grep texi2dvi
/usr/lib/R/bin/texi2dvi
$

I replace some scripts, such as libtool, with wrappers:

$ tail -1 /usr/lib/R/bin/libtool
exec /usr/bin/libtool "$@"
$

R-devel now has a libtool dependency, generated by shell.req:

$ rpm -qR R-devel |grep libtool
libtool-common
$ rpm -qf /usr/bin/libtool
libtool-common-0.2-alt1
$

However, I want the very same dependency SIMPLY BY PLACING SYMBOLIC LINK
to /usr/bin/libtool.  My new script symlinks.req implements this idea.

It works as follows:

1) We check all absolute symbolic links, e.g. -> /usr/bin/libtool.
If symbolic link is absolute, we fetch its value and feed to FindPackage.
Note that FindPackage will first check whether e.g. /usr/bin/libtool is
available under RPM_BUILD_ROOT.

2) We also check all broken symbolic links, e.g. -> ../../../bin/libtool.
The fact that symbolic link is broken means that it cannot be resolved into
buildroot and otherwise must be resolved in the host system after the package
is installed, which is the dependency on where it would point to after install.

This means we must canonicalize the link value, strip RPM_BUILD_ROOT,
and then call FindPackage.  Here is what happens:

$ cd `mktemp -d`
$ RPM_BUILD_ROOT=$PWD
$ mkdir -p ./usr/lib/R/bin/
$ ln -s `relative /usr/bin/libtool /usr/lib/R/bin/libtool` $RPM_BUILD_ROOT/usr/lib/R/bin/libtool
$ l $RPM_BUILD_ROOT/usr/lib/R/bin/libtool
lrwxrwxrwx 1 at at 20 Mar  9 22:14 /tmp/.private/at/tmp.AHnBX26473/usr/lib/R/bin/libtool -> ../../../bin/libtool
$ [ -e $RPM_BUILD_ROOT/usr/lib/R/bin/libtool ] || echo broken
broken
$ readlink -vm $RPM_BUILD_ROOT/usr/lib/R/bin/libtool
/tmp/.private/at/tmp.AHnBX26473/usr/bin/libtool
$ to=`!!`; echo ${to#$RPM_BUILD_ROOT}
/usr/bin/libtool
$

And then FindPackage is called with "/usr/bin/libtool".

Now note that if FindPackage is not able to associate e.g. /usr/bin/libtool
with any particular rpm package, it will just place raw dependency on
/usr/bin/libtool.  So, this new type of dependencies is a bit dangerous:
basically for each really broken symbolic link there will be an unmet
dependency.  On the other hand, this can be viewed as a means of protection
from packages with really broken symbolic links.

If you are frightened with this brand new and dangerous type of dependencies,
please also note that this new type of dependencies is not much more dangerous
than absolute paths to executables in plain shell scripts.

$ /usr/lib/rpm/shell.req -v /dev/stdin <<</i/am/unmet
error: file /i/am/unmet: No such file or directory
shell.req: /dev/stdin: /i/am/unmet -> /i/am/unmet (raw, not found)
/i/am/unmet
$
2007-03-12 15:06:09 +03:00

10 lines
183 B
Bash
Executable File

#!/bin/sh -efu
while IFS=$'\t' read -r f t; do
case "$t" in
*'symbolic link to `/'*)
echo "$f"; continue ;;
*'broken symbolic link to '*)
echo "$f"; continue ;;
esac
done