IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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.
The patterns used were OK for the output of "file -NF$'\t'": it would
put a space after the separator (the default separator being ":").
But not for the output of "file -b": we need to pad the result with a
space to use the same patterns.
Putting a space at the beggining is convenient, because it allows to
match independently for "* sh" or "* bash", otherwise "*sh" would
consume "bash", too.
Other uses of "file -b" in scripts/ don't suffer from this problem.
This is to improve 'buildreq -bi' support: 'type -t' will stat
absolute paths and buildreq will make self-dependency. Note
that in the next command PATH is nullified to avoid stat/search
for regular commands.
It seems that our /bin/bash interpreter does not have any "built-in"
functions by default.
$ bash -c 'foo() { :; }; set' |grep ' ()'
foo ()
$ bash -c 'set' |grep ' ()'
$
Thus funcions can be user-defined only. Generally, what was wrong
with this "function" check is that it was executed in shell.req context.
That is, since e.g. "Info" and "Fatal" are functions within shell.req,
all other dependencies on "Info" and "Fatal" were simply ignored.
This was wrong and this has now been fixed.
Another possibility to ignore current shell.req context while checking
for built-in things is to spawn "clean" shell instance:
- case "$(type -t -- "$2")" in
+ case "$($sh -c 'type -t "$1"' "$0" "$2")" in
But this can be rather expensive at this early "cleanup" stage.
There are two possibilities for protection:
1) we should protect at least from very evil shell metacharacters,
like [$*], and also from [:cntrl:] (e.g. newline).
2) we can provide an exhaustive list of characters that are valid
for non-evil pathnames and commands, and issue mandatory warning
if the command or path appears to be evil.
I chose the latter approach.
Valid character range is 'A-Za-z0-9/@=.,:_+-'.
Note that (almost) all files from our base build system
are valid paths:
$ valid='A-Za-z0-9/@=.,:_+-'
$ hsh-run -- rpm -qal |grep "[^$valid]"
/usr/bin/[
/usr/share/man/man1/[.1.bz2
(contains no files)
(contains no files)
$
Later we'll see if the range of valid characters needs to be extended.
There's a bug in "sh --rpm-requires" mode:
$ sh --rpm-requires /dev/stdin <<<'exec -a PERL /usr/bin/perl'
executable(-a)
$
Then "-a" is passed to grep as its first argument (search pattern).
See my previous commit. It goes like this:
$ /usr/lib/rpm/shell.req -v /usr/bin/buildreq
shell.req: /usr/bin/buildreq: cat -> /bin/cat -> coreutils (via rpmdb)
shell.req: /usr/bin/buildreq: cmp -> /usr/bin/cmp -> diffutils (via rpmdb)
shell.req: /usr/bin/buildreq: function(Info) not found (skip)
shell.req: /usr/bin/buildreq: function(show_help) not found (skip)
shell.req: /usr/bin/buildreq: function(show_usage) not found (skip)
shell.req: /usr/bin/buildreq: rm -> /bin/rm -> coreutils (via rpmdb)
shell.req: /usr/bin/buildreq: sed -> /bin/sed -> sed (via rpmdb)
coreutils
diffutils
sed
$
I argue that this behaviour, i.e. function(Info) processing, is erroneous.
There are two reasons: 1) it is impossible to resolve function(Info) neither
via FindPackage nor via .provides.sh (the latter has just plain function names);
2) the fact that Info has been detected as function means that Info() function
is defined in the very same file, i.e. /usr/bin/buildreq. This means that
function(Info) is self-provided dependency and thus should not be processed
at all.
1) added scripts/shell.req.files and scripts/shell.prov.files.
scripts/shell.req.files has new patterns for '/usr/bin/env bash'
and '/bin/ash'.
2) adapted scripts/shell.req.in and scripts/shell.prov.in
by using ArgvFileAction. Also made them work with empty RPM_BUILD_ROOT.
Note: now shell.req produces dependencies from .provides.sh even
if the latter is inside RPM_BUILD_ROOT. The reason is that .provides.sh
and the script can reside in two different subpackages (and otherwise,
rpm will optimize out the dependency).
3) removed corresponding old code from autodeps/linux.req.in
and autodeps/linux.prov.in.
