sinjuginas/rpm-build
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
2,547 Commits 1 Branch 0 Tags 4.5 MiB
sisyphus
Commit Graph

4 Commits

Author SHA1 Message Date
Arseny Maslennikov
76fa8b1172 Rename find-package to solve misconflict with rpm 
It is not that easy to ship find-package as part of rpm-build.
We have to drop find-package from the filelist of rpm as well. For this
change to enter Sisyphus, both rpm-build and rpm have to be changed and
rebuilt in their own base build chroots.

If rpm-build is built to include find-package first, rpm is
uninstallable in the base chroot due to a misconflict, so it cannot be
rebuilt.
If rpm is built to exclude find-package first, it disappears from the
base chroot altogether, making rpm-build break, so no
package can be built as well.
 2024-03-04 20:36:26 +03:00
Arseny Maslennikov
6bfa4a28aa /usr/lib/rpm/functions: split away to rpmb-functions 
In an environment created by `hsh --initroot-only`:
  $ for i in /usr/lib/rpm/*; do rpm -qf --qf='%{name}: '"$i"'\n' "$i"; done | grep '^rpm:'
  rpm: /usr/lib/rpm/0ldconfig.filetrigger
  rpm: /usr/lib/rpm/GROUPS
  rpm: /usr/lib/rpm/find-package
  rpm: /usr/lib/rpm/functions
  rpm: /usr/lib/rpm/macros.d
  rpm: /usr/lib/rpm/pdeath_execute
  rpm: /usr/lib/rpm/platform
  rpm: /usr/lib/rpm/posttrans-filetriggers
  rpm: /usr/lib/rpm/postupdate
  rpm: /usr/lib/rpm/rpmd
  rpm: /usr/lib/rpm/rpmdb_loadcvt
  rpm: /usr/lib/rpm/rpme
  rpm: /usr/lib/rpm/rpmi
  rpm: /usr/lib/rpm/rpmk
  rpm: /usr/lib/rpm/rpmpopt-4.13.0.1
  rpm: /usr/lib/rpm/rpmq
  rpm: /usr/lib/rpm/rpmu
  rpm: /usr/lib/rpm/rpmv

The `scripts/functions` file is provided from the rpm project in real
installations. Let's ensure scripts in this package use the functions
file from this package.
 2024-03-03 23:38:10 +03:00
Alexey Tourbin
347a9eb418 symlinks.req: do only one single step of symlink resolution 2007-11-17 10:52:57 +03:00
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