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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In build.c:checkSpec(), build dependencies are checked by creating
a transaction, adding source header to the transaction and then running
rpmdepCheck(). Source headers have only BuildRequies and BuildConflicts
types of dependencies (no regular Requires and Conflicts). Also, source
packages have no Provides, but they have NAMES. When a self-conflicting
package is installed, its self conflict will be triggered by the source
package name.
To fix the problem, note that binary packages explicitly provide
their N=EVR among Provides; and source packages provides nothing,
even the name. So the solution is as simple as not to check
the dependencies against package names.
Update: also, do not check installed Requires against erasedPackages names.
Only for the last two weeks or so, the issues has been raised twice.
By specifying "Provides: foo, Conflicts: foo", people expect that
other packages which provide "foo" will not be installed along with
the package. What people don't anticipate is that the package will
conflict with itself, and will not be installed at all. This is where
apt and rpm differ. In apt, "conflicts may never self match". In rpm,
Requires and Conflicts are handled in exactly the same way, except that
Requires should match, and Conflicts should not match (I call this
a symmetry). Both can match against the package they come from.
So, to permit self-conflicting packages, I have to break the symmetry
and pass additional argument which indicates the type of dependency
being processed (either Requires or Conflicts). The code is then
adjusted to discard self-matching Conflicts.
Obsoletes should be handled specially, too. In tsSatisfiesDepend(),
I attempt to handle the Obsoletes case as well. It is rather
unfortunate that, in rpmdepCheck(), Obsoletes are simply not checked
just yet.
My previous assumption that strdup() was not needed for dbProvCache keys
was wrong. The keys point to header memory, which is right. However,
those are not only ts->addedPackages and ts->erasedPackages headers.
In checkDependent(), headers come from rpmdb and are disposed immediately
after the check.
Based on rpm.org 2e76d0e6 by Panu Matilainen:
> Add in-memory hash for caching rpmdb dependency lookups
> - worst case behavior for uncached dependency lookups can be disastrous,
> eg > 35s vs < 1s on my laptop for trying to remove /bin/sh provider
> - we only bother caching rpmdb lookups, the other cases plenty fast already
> - using in-memory cache avoids nasty in vs out of chroot issues with
> temporary db files, which otherwise were about as fast
However, we do not use full-blown printDepend-based caching (i.e.
we no longer cache depends with versions). This is because, well,
dependency versions are likely to differ. This is especially true
if we consider upcoming set-versions for soname symbols - hashing
symbol sets here will be just a waste of time and memory. And so
now we cache satisfied/unsatisfied depends by just name. Thus,
"yes" hit can be used immediately only for unversioned dependences.
Top 10 dependencies which will be handled by the cache:
$ rpm -qaR |grep -v rpmlib |grep -v = |sort |uniq -c |sort -n |tail
245 /usr/lib/perl5/vendor_perl
311 libm.so.6(GLIBC_2.2.5)(64bit)
386 libpthread.so.0(GLIBC_2.2.5)(64bit)
454 /lib64/ld-linux-x86-64.so.2
548 libc.so.6(GLIBC_2.3)(64bit)
587 /bin/sh
828 libc.so.6(GLIBC_2.3.4)(64bit)
906 libc.so.6(GLIBC_2.4)(64bit)
1128 rtld(GNU_HASH)
1140 libc.so.6(GLIBC_2.2.5)(64bit)
$
Top 10 dependencies which will not be handled by the cache:
$ rpm -qaR |grep -v rpmlib |grep -e = |sort |uniq -c |sort -n |tail
13 python-base = 2.6.5-alt2
14 mono(mscorlib) = 1.0
15 qt4-common = 4.6.2-alt6
16 mono(mscorlib) = 2.0
18 mktemp >= 1:1.3.1
20 koffice-common = 4:2.2.0-alt2
20 perl-base >= 1:5.8.0
23 alternatives >= 0:0.4
49 libqt4-core >= 4.6.2
54 perl-base >= 1:5.6.0
$
Here's a simple test to see if the cache works (using Panu's example -
trying to remove /bin/sh).
(before this change)
$ time LD_LIBRARY_PATH=$PWD/1 rpm -e --test sh 2>&1 |tail
/bin/sh is needed by groff-base-1.20.1-alt0.20091013
/bin/sh is needed by groff-base-1.20.1-alt0.20091013
/bin/sh is needed by groff-base-1.20.1-alt0.20091013
/bin/sh is needed by libgnome-sharp-2.24.1-alt1
/bin/sh is needed by kernel-image-std-def-2.6.32-alt15
/bin/sh is needed by kernel-image-std-def-2.6.32-alt15
/bin/sh is needed by kde4libs-4.4.5-alt1
/bin/sh is needed by kde4base-runtime-core-4.4.5-alt1
/bin/sh is needed by kde4base-konqueror-4.4.5-alt1
/usr/lib/bash is needed by bash-builtin-lockf-0.3.1-alt1
rpm -e --test sh 2>&1 6.18s user 3.44s system 94% cpu 10.182 total
$
(after this change)
$ time LD_LIBRARY_PATH=$PWD/2 rpm -e --test sh 2>&1 |tail
/bin/sh is needed by groff-base-1.20.1-alt0.20091013
/bin/sh is needed by groff-base-1.20.1-alt0.20091013
/bin/sh is needed by groff-base-1.20.1-alt0.20091013
/bin/sh is needed by libgnome-sharp-2.24.1-alt1
/bin/sh is needed by kernel-image-std-def-2.6.32-alt15
/bin/sh is needed by kernel-image-std-def-2.6.32-alt15
/bin/sh is needed by kde4libs-4.4.5-alt1
/bin/sh is needed by kde4base-runtime-core-4.4.5-alt1
/bin/sh is needed by kde4base-konqueror-4.4.5-alt1
/usr/lib/bash is needed by bash-builtin-lockf-0.3.1-alt1
rpm -e --test sh 2>&1 0.11s user 0.09s system 91% cpu 0.218 total
$
Before this change, only rpm headers for addedPackages were loaded
during transaction; for removedPackages, we only stored the list
of rpmdb header numbers (numeric instances). With this change,
removedPackages' headers are getting loaded, too (the list is called
erasedPackages). The reason is that, when a header is loaded,
it is possible to use pointers to point e.g. into header strings
without using strdup. This might come useful as we try to reimplement
the depends cache.
Based on rpm.org 6bc5d870 by Panu Matilainen:
> Rip out dependency caching
> - it doesn't speed up things that much, is broken in some chroot
> scenarios and is ugly ugly hardwired BDB hackery where it doesn't belong
- continue processing as long as progress can be made instead of artificial
hardcoded magic "try ten times"
[rpm.org f39d2432f74bdc328ceafa8abc6cac517e02c73b]
This should facilitate library upgrades, e.g. glibc-prthread.
Consider that we upgrade gcc-* and glibc-* packages; and glibc
has new subpackage glibc-pthread (with libpthread and librt
shared libraries).
Old order was:
D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth)
D: 0 0 14 0 0 glibc-preinstall-2.8.90-alt3
D: 1 1 21 0 1 glibc-core-2.8.90-alt3
D: 2 1 9 0 2 cpp4.3-4.3.2-alt5
D: 3 1 5 0 2 libgcc4.3-4.3.2-alt5
D: 4 2 13 0 3 glibc-pthread-2.8.90-alt3
D: 5 2 20 0 4 glibc-core-debug-2.8.90-alt3
D: 6 2 17 0 4 glibc-gconv-modules-2.8.90-alt3
D: 7 2 16 0 4 glibc-locales-2.8.90-alt3
D: 8 2 15 0 4 glibc-nss-2.8.90-alt3
D: 9 2 12 0 4 glibc-timezones-2.8.90-alt3
D: 10 2 11 0 4 glibc-utils-2.8.90-alt3
D: 11 2 10 0 5 iconv-2.8.90-alt3
D: 12 8 22 0 6 glibc-2.8.90-alt3
D: 13 4 19 0 7 glibc-devel-2.8.90-alt3
D: 14 1 18 0 8 glibc-devel-static-2.8.90-alt3
D: 15 4 8 0 8 gcc4.3-4.3.2-alt5
D: 16 1 4 0 2 libgfortran4.3-4.3.2-alt5
D: 17 2 3 0 3 libgfortran4.3-devel-4.3.2-alt5
D: 18 3 6 0 4 gcc4.3-fortran-4.3.2-alt5
D: 19 2 2 0 3 libstdc++4.3-4.3.2-alt5
D: 20 2 1 0 4 libstdc++4.3-devel-4.3.2-alt5
D: ========== successors only (presentation order)
D: 21 3 7 0 5 gcc4.3-c++-4.3.2-alt5
Note that #succesors value is actually changed using the package index
in the input list of packages (on the command line): earlier packages
have higher values. This is called "successors from tsort are processed
in presentation order". E.g. when choosing to upgrade between cpp4.3,
libgcc4.3, and libgfortran4.3, cpp4.3 gets upgraded first. (The
collation is probably due to using shell glob on the command line.)
The problem is that, in cpp4.3 %post-script, some pthread-dependent
code might be called, and pthread shared library is simply mssing
at that point (after glibc-core upgrade and before glibc-pthread
install).
New order is:
D: ========== tsorting packages (order, #predecessors, #succesors, tree, depth)
D: 0 0 1 0 0 glibc-preinstall-2.8.90-alt3
D: 1 1 17 0 1 glibc-core-2.8.90-alt3
D: 2 1 3 0 2 libgcc4.3-4.3.2-alt5
D: 3 2 8 0 3 glibc-pthread-2.8.90-alt3
D: 4 2 2 0 4 glibc-gconv-modules-2.8.90-alt3
D: 5 2 2 0 4 glibc-nss-2.8.90-alt3
D: 6 2 1 0 5 iconv-2.8.90-alt3
D: 7 2 1 0 4 glibc-locales-2.8.90-alt3
D: 8 2 1 0 4 glibc-timezones-2.8.90-alt3
D: 9 2 1 0 4 glibc-utils-2.8.90-alt3
D: 10 8 1 0 5 glibc-2.8.90-alt3
D: 11 4 4 0 6 glibc-devel-2.8.90-alt3
D: 12 2 1 0 3 libstdc++4.3-4.3.2-alt5
D: 13 2 1 0 4 libstdc++4.3-devel-4.3.2-alt5
D: 14 1 1 0 2 cpp4.3-4.3.2-alt5
D: 15 4 2 0 3 gcc4.3-4.3.2-alt5
D: 16 1 1 0 2 libgfortran4.3-4.3.2-alt5
D: 17 2 1 0 3 libgfortran4.3-devel-4.3.2-alt5
D: ========== successors only (presentation order)
D: 18 2 0 0 4 glibc-core-debug-2.8.90-alt3
D: 19 1 0 0 7 glibc-devel-static-2.8.90-alt3
D: 20 3 0 0 4 gcc4.3-fortran-4.3.2-alt5
D: 21 3 0 0 4 gcc4.3-c++-4.3.2-alt5
Note that #succesors now indicates the number of immediate successors;
libgcc4.3 now has 3 immediate successors (glibc-pthread, gcc4.3, and
libstdc++4.3), while cpp4.3 and libgfortran4.3 have only one immediate
successor.
Also removed tools/rpmsort.c.
> The are various serial representations of a partially ordered set.
>
> The default is what I call "chainsaw", always emit the node that has
> the most children. The "chainsaw" heuristic tries to emit nodes that
> are depended upon as early as possible to localize interactions
> amongst packages, but really should be
> Always emit the node of the largest sub-tree.
> rather than the number of immediate children. I call this "buzzsaw".
>
> Anaconda has the constraint of changing cd's during install. So
> "presentation" ordering preserves the arrival ordering into a
> transaction set. Too bad that "presentation" ordering is often
> incorrect because of no loop analysis first.
https://lists.dulug.duke.edu/pipermail/rpm-devel/2005-June/000468.html
