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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
(old)
$ apt-cache whatdepends perl-Bit-Vector
perl-Bit-Vector-6.4-alt2
$
(new)
$ ./cmdline/apt-cache whatdepends perl-Bit-Vector
perl-Bit-Vector-6.4-alt2
perl-Date-Calc-5.4-alt2
Depends: <perl(Bit/Vector.pm)>
perl-Bit-Vector-6.4-alt2
$
Note that perl-Date-Calc has versioned virtual dependency:
$ rpm -qR perl-Date-Calc |grep Vector
perl(Bit/Vector.pm) >= 6.400
$
The problem was that version comparison was performed against
perl-Bit-Vector version (which is 6.4-alt2), not against provided
perl(Bit/Vector.pm) version (which is 6.400).
$ diff -U1 <(apt-cache whatdepends perl-base) <(./cmdline/apt-cache whatdepends perl-base)
--- /tmp/.private/at/zshtuurCP 2009-08-03 15:45:46 +0400
+++ /tmp/.private/at/zshfynbjW 2009-08-03 15:45:46 +0400
@@ -7145,2 +7145,5 @@
perl-base-1:5.8.9-alt3
+ perl-HTML-FromText-2.05-alt3
+ Depends: <perl(Text/Tabs.pm)>
+ perl-base-1:5.8.9-alt3
perl-Getopt-ArgvFile-1.10-alt2
@@ -8458,4 +8461,2 @@
perl-base-1:5.8.9-alt3
- perl-base-1:5.8.9-alt3
- Obsoletes: <perl-MIME-Base64>
nix-0.12-1
Again, this shows that versioned virtual dependencies are handled
properly now, more or less. However, there is also a change in
"Obsoletes" which I did not expect.
apt/apt-pkg/rpm/rpmversion.cc:
| // rpmVS::CheckDep - Check a single dependency /*{{{*/
| // ---------------------------------------------------------------------
| /* This prototype is a wrapper over CheckDep above. It's useful in the
| cases where the kind of dependency matters to decide if it matches
| or not */
| bool rpmVersioningSystem::CheckDep(const char *PkgVer,
| pkgCache::DepIterator Dep)
| {
| if (Dep->Type == pkgCache::Dep::Obsoletes &&
| (PkgVer == 0 || PkgVer[0] == 0))
| return false;
| return CheckDep(PkgVer,Dep->CompareOp,Dep.TargetVer());
| }
I'm not sure if this "Obsoletes" logic should be enabled in WhatDepends.
But at least it can show "Requires" now, which is what I need.
- unmunge the multilib package names when removing
- always refer to packages with their architecture when removing, needed
for multilib
(cherry picked from commit 0463f8ddbabf216dab9cb83fcb8f4a525d9298e5)
Consider a package called "test":
Name: test
Version: 1
Release: alt1
Summary: test
License: GPL
Group: Development/Other
Requires: /usr/bin/latex
Requires: tetex-latex
%description
%files
The problem with this "test" package is that it cannot be installed.
Since recently, Sisyphus has two packages which provide /usr/bin/latex:
tetex-latex and texlive-latex-base. These two packages conflict with
each other. When /usr/bin/latex dependency is processed, apt chooses
to install texlive-latex-base. And after a short while, apt also has
to choose tetex-latex. Since there are also other packages involved
(e.g. tetex-core and texlive-base), ProblemResolver fails to fix the
conflict.
The following packages have unmet dependencies:
test: Depends: tetex-latex
E: Broken packages
To avoid the problem (to to a large extent), apt should process
non-ambiguous dependencies first. That would be tetex-latex.
After tetex-latex is selected for install, ambigous dependency
on /usr/bin/latex will be automatically satisfied.
This change implements recursive wavefront algorithm that helps
to disambiguate dependencies gradually. The recursive function
MarkInstallRec() has "Restricted" flag, by which it avoids to mark
ambiguous dependencies, and instead returns "MarkAgain" set of
packages. Moreover, Restricted flag is automatically re-enabled
on recursive invocations (in other words, ambiguous dependencies
can be resolved only on the current wavefront).
MarkAgain packages must be marked again. There are two possibilities.
Either marking again does nothing, because previously marked unambiguous
dependencies now satisfy ambiguous dependencies (that's where I'm trying
to get to). And otherwise, the package has to be marekd without
Restricted flag, to force ambiguous selection (which cannot be
completely avoided).
Here is the piece of code that does full recursive mark.
std::set<PkgIterator> MA;
std::set<PkgIterator>::iterator I;
MarkInstallRec(Pkg, true, MA, 0, DebugA);
while (1) {
std::set<PkgIterator> MAA;
for (I = MA.begin(); I != MA.end(); ++I)
MarkInstallRec(*I, true, MAA, 0, DebugB);
for (I = MA.begin(); I != MA.end(); ++I)
MarkInstallRec(*I, false, MAA, 0, DebugC);
if (MA == MAA)
break;
MA = MAA;
}
First, I mark the package with Restricted=true, and see if something
needs to be marked again because of ambiguous dependencies. The loop
then says: before we can go with Restricted=false and grab some
ambiguous dependencies, we need to mark all non-ambigous dependencies
first. The loop ends when no new packages can be marked (which is
usually when MA gets empty).
With '-o Debug::pkgMarkInstall=1' option, it is now possible to
show how apt deals with the "test" package.
MI2a: mark test
MI2a: target /usr/bin/latex AMB
MI2a: target tetex-latex
MI2a: mark tetex-latex
MI2a: target tetex-core
MI2a: mark tetex-core
MI2a: target dialog
MI2a: mark dialog
MI2a: target /etc/cron.daily
MI2a: mark crontabs
MI2a: target vixie-cron
MI2a: mark vixie-cron
MI2a: target crontab-control
MI2a: mark crontab-control
MI2a: target libsetproctitle.so.0()(64bit)
MI2a: mark setproctitle
MI2a: target /etc/tex-fonts.d
MI2a: mark tex-common
MI2a: target /usr/sbin/stmpclean
MI2a: mark stmpclean
MI2a: target ed
MI2a: mark ed
MI2a: target libpng12.so.0(PNG_12)(64bit)
MI2a: mark libpng12
MI2a: target libstdc++.so.6(CXXABI_1.3)(64bit) AMB
MI2a: target libstdc++.so.6(GLIBCXX_3.4)(64bit) AMB
MI2a: target texinfo
MI2a: mark texinfo
MI2b: mark tetex-core
MI2b: target libstdc++.so.6(CXXABI_1.3)(64bit) AMB
MI2b: target libstdc++.so.6(GLIBCXX_3.4)(64bit) AMB
MI2c: mark tetex-core
MI2c: target libstdc++.so.6(CXXABI_1.3)(64bit)
MI2c: mark libstdc++4.3
Each rpm package also provides its name. So, since it makes sense
to check if AllTargets has only one target version (which means
unambiguous dependency), the list sould be made unique.
- apt-shell: show up "list" command by completion (#5953)
- apt-shell: quit from shell by Ctrl+D (#6264, #18343)
- apt-shell: describe -G and -g options in "help list" output (#18256)
- fix by led@: change type of Package.ID to int (fixes#16900)
- fixes by raorn@:
- apt-get.cc: protect VerTag (fixes#16311)
- apt-get.cc: fix memory corruption (fixes#14929)
- fileutl.cc: change semantics of flExtension() (fixes#15909)
- genpkglist.cc: RPMTAG_FILEFLAGS should not be copied into header list
- lorg-cache-limit.patch: increase cache size limit
- removed old triggers, updated dependencies
Before this patch, strcmp(3) would be used to select
the best package. This was sometimes counter-intuitive
(for example, APT would choose autoconf_2.5 over
autoconf_2.13).
[NB: fixing this can break some packages that rely
on the historic sort order; e.g. postgresql74
may be preferred to postgresql8.2.]
We considered using rpmvercmp() for package name
comparison, but chose to write a specially-crafted
function that's mostly compatible with strcmp(3),
except for numeric fragments in the names.
As a matter of fact, strtoull usage is suboptimal here.
It may overflow the returned long long, leading to an
incorrect comparison. Fixing the code to avoid strtoull
is, however, left as an exercise to the diligent
maintenance programmer (and you are insane anyway
if you need package names that trigger the overflow).
