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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- 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).
There was an assumption that DIRINDEXES are always sorted ascending,
which actually does not hold. This means we CANNOT use inplace
replacement in "dirnames" array, so as to append "later dirs" on top
of "older dirs".
The bug can actually be more subtle. It is very well possible that
I simply cannot understand that previous "inplace optimization" logic.
But I think that it sucks anyway. I choose to rewrite this piece of code
for the sake of clarity and correctness. I hope that the correctness of
the code now should be a bit more obvious, even for a casual reader.
- genpkglist: removed very bad piece of code which could break
my fine-grained file list stripping algorithm
- genbasedir: made silent by default, added --verbose and --silent
options (Alex V. Myltsev)
- genpkglist: don't strip paths that are owned by 2 or more packages,
to deal with cross-arch semi-unmets like /usr/share/wallpapers
- apt-get: added support of manifest file (Stanislav Ievlev)
Another attempt to deal with semi-unmet dependencies. This should fix
most of the cross-arch semi-unmets generated via conetnts_index_all.
Consider a few noarch packages which own /usr/share/foo. Now if i586
package somehow refers /usr/share/foo, contents_index_all search will
produce as-is reference, which is going to be cross-arch semi-unmet.
Note that if /usr/share/foo is owned by only one package,
contents_index_all search will produce explicit package name.
This is why genpkglist should not strip paths that are owned
by 2 or more packages.
