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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
