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 will also check if the link is not owned by any package,
but the path is provided by some package.
$ rpm -qf /usr/bin/python
warning: file /usr/bin/python is not owned by any package
$ rpm -q --whatprovides /usr/bin/python
python-base-2.4.4-alt13
$
This looks very much like an alternative, ESPECIALLY if an intermediate
path component, which is a link to directory (python is not the case).
This new condition is disabled, only a warning is issued.
We'll see if it should be enabled.
Note that alternative path may also require non-blind canonicalization (in
very pathological cases), for which I also use CanonPath.
(old behaviour, wrong)
$ sudo ln -s share /usr/bare
$ sh -efu -c '. scripts/find-package.in; FindPackage script /usr/bare/libtool/config.guess'
/usr/bare/libtool
sh: script: alternative /usr/bare/libtool prevents /usr/bare/libtool/config.guess dependency resolution
$
(new behaviour, good)
$ sh -efu -c '. scripts/find-package.in; FindPackage script /usr/bare/libtool/config.guess'
/usr/share/libtool
sh: script: alternative /usr/share/libtool prevents /usr/bare/libtool/config.guess dependency resolution
$
Some examples.
1)
$ sh -efu -c '. scripts/find-package.in; FindPackage script /usr/share/libtool'
/usr/share/libtool
$ sh -efu -c '. scripts/find-package.in; FindPackage script /usr/share/libtool/'
/usr/share/libtool
$
This shows that alterntaives check is no longer restricted to deficient
readlink "$rep" |grep '^/etc/alternatives/'
logic. Old behaviour was:
$ sh -efu -c '. /usr/lib/rpm/find-package; FindPackage script /usr/share/libtool'
/usr/share/libtool
$ sh -efu -c '. /usr/lib/rpm/find-package; FindPackage script /usr/share/libtool/'
sh: script: checking contents_index_all for /usr/share/libtool-1.5
sh: script: /usr/share/libtool-1.5 -> libtool_1.5 (via contents_index_all)
libtool_1.5
$
2)
$ sh -efu -c '. scripts/find-package.in; FindPackage script /usr/share/libtool/../autoconf'
/usr/share/autoconf
/usr/share/libtool
$
This shows that any number of alternatives can be resolved within a single path.
3)
$ sh -efu -c '. scripts/find-package.in; FindPackage script /usr/share/libtool/config.guess'
/usr/share/libtool
sh: script: alternative /usr/share/libtool prevents /usr/share/libtool/config.guess resolution
$
This shows that we cannot resolve paths under alternatives directory.
4)
$ sh -efu -c '. scripts/find-package.in; FindPackage script /usr/share/libtool/../../bin/perl'
/usr/share/libtool
perl-base
$
This shows that we actually CAN resolve paths which are not under alternatives directory.
This is to address a few problems:
1) When checking RPM_BUILD_ROOT, st_mode test performed by /usr/bin/which
is not quite reliable. Files can be packaged with different %attr mode.
2) When checking RPM_BUILD_ROOT, there could be symbolic links there
which are (not-so-) broken.
3) When checking host system, files like /sbin/init (which is 0700)
are effectively bypassed by /usr/bin/which.
4) There's an ongoing practice of placing shell function libraries
under /usr/bin, e.g. /usr/bin/git-sh-setup. These files are sourced
from within shell scripts and need not be executable at all.
This leads me to the point that permission check, which is performed by
/usr/bin/which, is not needed at all. Note that things are getting more like
contents_index_bin search. And for RPM_BUILD_ROOT, we do not even require
strong stat-wise file existence.
I like this new term: "strong stat-wise file existence".
It's awesome.
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.
I see that this can add SOME problems if e.g. /usr is relocated
to /storage/usr in the build environment. This is because CanonPath
follows symlinks for dirname.
But I argue that it is safe for hasher, and it fixes some problems
with contents_index search which is used only in the hasher (by default).
I also argue that, even if /usr is relocated, this is not going to be a BIG
problem, because it is not going to produce unmet dependencies (well, most
of the time). This is because 'rpm -qf' will work as expected in that screwed
build environment.
When something goes not as good as we would like, we should
be able to increase verbosity locally for this particular case.
Old behaviour:
$ sh -efu -c '. /usr/lib/rpm/find-package; RPM_PKG_CONTENTS_INDEX_ALL=/etc/passwd FindPackage myscript /bin/cat'
sh: myscript: checking contents_index_all for /bin/cat
coreutils
$
In this example I pretend that /bin/cat lookup failed against
contents_index_all. The problem here is that, once we know about
a "strange thing" happening, we also want to know the end of the story.
Where does coreutils come from? That is the question.
New behaviour:
$ sh -efu -c '. /usr/lib/rpm/find-package; RPM_PKG_CONTENTS_INDEX_ALL=/etc/passwd FindPackage myscript /bin/cat'
sh: myscript: checking contents_index_all for /bin/cat
sh: myscript: /bin/cat -> coreutils (via rpmdb)
coreutils
$
When "strange things" happen, I increase verbosity locally,
until the "strange thing" is resolved. I use 'local Verbose=Info'
approach to increase verbosity. Since shell has dynamic variables
(with visibility bound to function-call stack), this is just what
we need.
Strange things are:
- in FindByPath:
+ contents_index_all search
- in FindByName:
+ ambiguous contents_index_bin search
(the same command under e.g. /sbin and /usr/bin)
+ ambiguous /usr/bin/which search (ditto)
In FindByPath, we should always check contents_index_bin first.
It is not quite expensive, and we make no assumptions which path
entries it may contain (our contents_index_bin, in addition
to standard *bin/ paths, also has /etc entries).
However, if contents_index_bin lookup fails, we may or may
not want to proceed with very expensive contents_index_all
search. We assume that, if contents_index_bin lookup actually
has take place for some standard *bin/ path, then there is simply
no need to proceed with contents_index_all.
Now we also assume that contents_index_all file can be possibly
gzipped (I use "gzip -cdfq" for "zcat or cat", found in zgrep).
Also increased verbosity (Verbose to Info) for contents_index_all
messages, since it is expensive and it is a means of "last resort"
to finding something strange before giving up, which is quite worth
to note about.
Also increased verbosity for "raw, not found" dependencies,
since they are likely to become unmet.
E.g. if the content index search detected something like
/usr/bin/arpsend -> arpsend
/usr/sbin/arpsend -> vzctl
then we should consult the host system first. There's a good chance
that the right package, either arpsend or vzctl, IS installed, and
other candidate packages are NOT installed. However, if /usr/bin/which
cannot find any candidate, we should reconsult the index again.
There's been a few problems.
1) ~/bin should not be checked.
$ /usr/lib/rpm/shell.req -v /dev/stdin <<<vim
warning: no package provides /home/at/bin/vim
shell.req: /dev/stdin: vim not found (skip)
$
Fortunately /usr/bin/which has --skip-tilde option.
2) Check for /etc/alternatives was missing.
$ PATH=/bin:/usr/bin /usr/lib/rpm/shell.req -v /dev/stdin <<<vim
shell.req: /dev/stdin: vim -> /usr/bin/vim -> vim-X11
vim-console
vim-enhanced (via rpmdb)
vim-X11
vim-console
vim-enhanced
$
This is why FindByName should ultimately call FindByPath.
After this change, it works just fine:
$ scripts/shell.req.in -v /dev/stdin <<<vim
shell.req.in: /dev/stdin: vim -> /usr/bin/vim -> ... (via which)
shell.req.in: /dev/stdin: /usr/bin/vim -> /usr/bin/vim (alternative)
/usr/bin/vim
$
Also enabled /usr/bin/which --all option and added diagnostics
for really ambiguous cases.
Actually if you think about it a few hours or so... you may come to
know that FindByName() should ultimately call FindByPath(). But this
will be the next commit.
Now it works 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
$
It looks like there's a problem with function(Info) here.
Verbosity is a good thing.
