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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There are two reasons:
1) It is better to verify final ELF objects just as they are packaged.
2) Older eu-elflint barks at unstripped binaries like this:
section [ 8] '.comment' has wrong flags: expected none, is MERGE|STRINGS
This seems to be fixed in elfutils 0.143-alt1, but otherwise that could
be a major problem.
Also, move RPM_VERIFY_ELF_SKIPLIST logic from verify-elf to
brp-verify_elf, since RPM_VERIFY_ELF_TOPDIR is already there.
Normally, verify-elf should be a standalone program (available
for users). It's just not quite ready yet.
file(1) sucks here, but we should handle one more common case.
$ file - <<<'#!/bin/ash'
/dev/stdin: a /bin/ash script text executable
$ file - <<<'#!/bin/ash -efu'
/dev/stdin: a /bin/ash -efu script text executable
$ file - <<<'#!/bin/ash -efu'
/dev/stdin: a /bin/ash -efu script text executable
$ file - <<<'#! /bin/ash -efu'
/dev/stdin: a /bin/ash -efu script text executable
$ file - <<<'#! /bin/ash -efu'
/dev/stdin: script text executable for /bin/ash -efu
$
- implemented post-transaction filetriggers, loosely based on filetriggers.patch
from Mandriva Linux (see %_rpmlibdir/posttrans-filetriggers for details)
- implemented %_rpmlibdir/0ldconfig.filetrigger, so that packages with
shared libraries need not to invoke ldconfig(1) in they %%post-scriptlets
- rpmlib.req: automatically generate rpmlib(PosttransFiletriggers) dependency
for packages which provide %_rpmlibdir/*.filetrigger programs
- implemented post-transaction filetriggers, loosely based on filetriggers.patch
from Mandriva Linux (see %_rpmlibdir/posttrans-filetriggers for details)
- implemented %_rpmlibdir/0ldconfig.filetrigger, so that packages with
shared libraries need not to invoke ldconfig(1) in they %%post-scriptlets
According to /usr/lib/ldscripts/elf_*,
- every ELF executable linked by GNU ld using one of default linker
scripts contains .interp section;
- every ELF shared library linked by GNU ld using one of default linker
scripts does not contain .interp section.
- build/reqprov.c: when folding duplicate dependencies, Requires(pre)
or Requires(post) should not opimitze out bare Requires
- build/files.c: execute find-requires before find-scriptlet-requires
- 0common-files.req.list: added /etc/rc.d/init.d (service)
1) In Linux, execve(2) does not split shebang arguments, which implies
that effectively only one argument can be passed to the interpreter.
However, some interpreters, esp. perl, can do a magic here, which is
to split its arguments.
2) Neither /usr/bin/env can split arguments, and no magic is possible
at all.
3) Interpreter path (or name) must not end with <CR>, otherwise execve
(resp. /usr/bin/env) is deemed to fail. However, some interpreters,
esp. perl, can strip trailing <CR> in its command line options.
This should affect dependencies only when no contents_index_bin is available.
After "APT-freindly" logic was introduced, host-system lookup always yields
file paths, but we want package names (except for alternatives etc.).
(old behaviour)
$ sh -c '. /usr/lib/rpm/find-package; FindPackage script perl'
/usr/bin/perl
$
(new behaviour)
$ sh -c '. ./scripts/find-package.in; FindPackage script perl'
perl-base
$
Some scripts like lib.req rely on the fact that RPM_BUILD_ROOT
should not end with trailing slashes or something. Other
scripts like find-package explicitly assume that RPM_BUILD_ROOT
can be relocated within filesystem; they use something like
"real_buildroot" variables. The code gets complicated,
fragile, and error-prone.
Therefore, guys, hereby I FORBID non-canonical RPM_BUILD_ROOT path.
Note that RPM_BUILD_ROOT actually does not have to exist.
This is another problem...
$ less alterator-install-common-desktop-0.11-alt1.i586.rpm |grep help
-rwxr-xr-x 1 root root 972 Oct 30 18:38 /usr/share/alterator/help/ru_RU/basesystem.html
-rwxr-xr-x 1 root root 340 Oct 30 18:38 /usr/share/alterator/help/ru_RU/kbd.html
-rwxr-xr-x 1 root root 2233 Oct 30 18:38 /usr/share/alterator/help/ru_RU/license.html
-rwxr-xr-x 1 root root 1280 Oct 30 18:38 /usr/share/alterator/help/ru_RU/lilo.html
-rwxr-xr-x 1 root root 3032 Oct 30 18:38 /usr/share/alterator/help/ru_RU/network.html
-rwxr-xr-x 1 root root 4840 Oct 30 18:38 /usr/share/alterator/help/ru_RU/packages.html
-rwxr-xr-x 1 root root 1928 Oct 30 18:38 /usr/share/alterator/help/ru_RU/root.html
-rwxr-xr-x 1 root root 1387 Oct 30 18:38 /usr/share/alterator/help/ru_RU/time.html
-rwxr-xr-x 1 root root 1223 Oct 30 18:38 /usr/share/alterator/help/ru_RU/user.html
-rwxr-xr-x 1 root root 11024 Oct 30 18:38 /usr/share/alterator/help/ru_RU/vm.html
-rwxr-xr-x 1 root root 1789 Oct 30 18:38 /usr/share/alterator/help/ru_RU/x11.html
lrwxrwxrwx 1 root root 31 Oct 30 18:38 /usr/share/alterator/help/ru_UA -> /usr/share/alterator/help/ru_RU
$
%files ...
%_datadir/alterator/help/ru_RU/*
%_datadir/alterator/help/ru_UA
The package referes ru_RU directory but does not own the directory.
Old behaviour: unmet dependency.
> alterator-icons-lite-0.4.0-alt1 Requires(rpmlib) rpmlib(PayloadFilesHavePrefix) <= 4.0-1
> +alterator-install-common-desktop-0.11-alt1 Requires /usr/share/alterator/help/ru_RU
> alterator-install-common-desktop-0.11-alt1 Requires alterator-autoinstall
New behaviour: though the package does not explicitly own the directory,
it has some files packaged under the directory. Because of this, ru_UA
symlink will not be broken after install. We chose to be forgiving:
symlinks.req: WARNING: /usr/src/tmp/alterator-install2-desktop-buildroot/usr/share/alterator/help/ru_UA: directory /usr/share/alterator/help/ru_RU not owned by the package
Private libraries are the ones which have non-standard prefix.
We choose to produce file-level dependency (without braces) on
such private libraries in two cases: 1) either the library was
found under RPM_BUILD_ROOT; or 2) no versioned symbols are used
from the library (no versioned references).
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.
This will allow to relax rpm-build-* dependencies, hopefully without adding
new essential dependencies to rpm (note that rpm already depends on sh and
coreutils; now this also includes grep, and possibly should include sed,
awk, and gzip).
Consider mono-mcs package, which is mono C# compiler. Recently I added
dependency on rpm-build-mono to this package, to enable automatic support
for mono dependencies whenever mono compiler is used. Now the problem
is that rpm-build-mono depends on rpm-build (via /usr/lib/rpm/functions),
and rpm-build in turn requires a lot of packages, e.g. gcc and autotools,
for the purpose of populating base build environment.
To put it another way, the problem is that it is impossible to install
mono compiler (with automatic support for mono dependencies) without also
installing gcc and stuff, which is roughly 100M of unrelated packages.
This seems like a minor problem to me, since every "devel" package (including
compilers) can conventionally require base build environment. However,
Alexander Bokovoy argues that school kids desperately need mono-mcs compiler
on their desktops without gcc and another stuff from the base build environment!
The upshot is that possibly we want to relax rpm-build-* dependencies,
so that those "support for dependencies" packages do not require
full-fledged rpm-build. The easiest way to accomplish this is to
move /usr/lib/rpm/functions from rpm-build to rpm package. I also
choose to move /usr/lib/rpm/find-package as well, along with making
/usr/lib/rpm/.provides.sh, so that rpm-build-* packages depend on
something like /usr/lib/rpm(Fatal), not just rpm.
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.
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
$
This removes the ambiguity with directories. Note that before this change,
e.g. [ -L /etc/init.d ] and [ -L /etc/init.d/ ] would yield different
result, which required ad hock -d test to keep things consistent.
With first-pass "blind" (cleanup-only) canonicalization, ad hock
test for directories is no longer required, and things are yet more
consistent.
The things are now consistent with documented behaviour -- "canonicalize
each path component except for the last". This actually changed previous
behaviour:
was: /etc/init.d -> /etc/rc.d/init.d
now: /etc/init.d -> /etc/init.d
Generally, if we have some path for which we should yield a dependency,
CanonPath is probably the best we can do before running e.g. contents_index
search.
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.
Fatal, Verbose, Debug: Use Info().
ValidateBuildRoot: Use single quotes for constant string.
SetupMethods: Do not initialize loop variable. Use "tr -s".
RunMethods: Do not initialize loop variable. Use "echo ''" trick. Cleanup "$@" use.
ArgvFileAction: Do not initialize auto variable.
'pkg-config --libs' seems to deploy dependencies recursively,
which is what I did not expect.
$ grep Requires pango.pc
Requires: glib-2.0,gobject-2.0,gmodule-no-export-2.0
$ grep Lib pango.pc
Libs: -lpango-1.0 -lm
$ pkg-config --libs-only-l pango.pc
-lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
$
I need some time to devise a better implementation.
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.
(old)
$ /usr/lib/rpm/pkgconfig.req /usr/lib/pkgconfig/gtkextra-2.0.pc
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gtk+-2.0', required by 'GtkExtra', not found
$
(new)
$ scripts/pkgconfig.req.in /usr/lib/pkgconfig/gtkextra-2.0.pc
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gtk+-2.0', required by 'GtkExtra', not found
pkgconfig.req.in: failed to process /usr/lib/pkgconfig/gtkextra-2.0.pc
$
$ ls /usr/lib/pkgconfig/*.pc >.1
$ ls /usr/lib/pkgconfig/*.pc |file -NF$'\t' -f - |./scripts/pkgconfig.req.files >.2
pkgconfig.req.files: /usr/lib/pkgconfig/libpng.pc: symbolic link to `libpng12.pc'
$ diff -U1 .1 .2
--- .1 2007-08-28 18:26:10 +0400
+++ .2 2007-08-28 18:26:13 +0400
@@ -115,3 +115,2 @@
/usr/lib/pkgconfig/libpcre.pc
-/usr/lib/pkgconfig/libpng.pc
/usr/lib/pkgconfig/libpng12.pc
$
Remember that symlinks are relevant only for find-requires.
There is no such thing as symbolic links in find-provides.
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.
This is actually a DWIM-style hack. It does what we want but I cannot
think of a better name. The idea is that sometimes we want to clean
up path name, possibly following symbolic links, except for the last
component, which we want to keep as is.
$ sh -c '. scripts/functions; CanonPath /etc/init.d/functions'
/etc/rc.d/init.d/functions
$ sh -c '. scripts/functions; CanonPath /usr/bin/../bin/perl'
/usr/bin/perl
$
So actually it does a few different things: 1) prepend $PWD if needed;
2) cleanup dirname; 3) canonicalize dirname with respect to symbolic links.
Now the question is how to process symbolic links which
targets are directories, e.g. /etc/init.d ? My answer is that
both "/etc/init.d" and "/etc/init.d/", as well as "/etc/init.d/."
should yield the same result, which is "/etc/rc.d/init.d".
