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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
rpm-build-mono has been adapted.
Updated rpm-build dependencies:
Conflicts: rpm-build-mono <= 1.0
rpm-build-java does NOT include java.req in current sisyphus release
1.0.0-alt1. I have done some major development for rpm-build-java,
but there is still no consensus about it.
Not updated rpm-build dependencies: nothing to do.
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.
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).
- Changed /mnt/* mountpoints handling to behave the same way
as other mountpoints.
- Fixed support of filesystems with f_bsize==0.
- files.req.list: Added /etc/hooks directory.
A few notes.
RPM uses only ^/etc/rpm/macros.d/[[:alnum:]_-]*[[:alnum:]]$
files to load macros. The dot is not possible here, so there
will be no conflict between *.env and non-env files.
/etc/rpm/macros.d is now possibly misused, since the name implies
there must be macros. However, *.env files can have macros, too.
The difference is that the macros from *.env files are expanded
and placed into %___build_pre, i.e. some rpm-tmp.* shell scripts.
Totally different semantics, but that's still about macros.
At least one *.env file is required to make 'cat *.env' happy.
I think I will updated the dependency on rpm-build-python,
which whill provide python.env file.
- find-provides, find-requires:
+ Added support for files of type "Mono/.Net assembly" to repair
Mono support when new file(1) is installed (#11088, ildar@).
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
$
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.
