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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
- 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.
genpkglist strips file lists by default (without --bloat option).
It keeps only some "useful files" by using a few ad hoc patterns.
This can break file-level dependencies. Consider pkgA requires
/usr/lib/foo1/bar, and pkgB owns this file without explicitly
providing it. Now if genpkglist strips /usr/lib/foo1/bar
from pkgB file list, this is going to be an unmet dependency.
This patch changes genpkglist behaviour, so that, when genpkglist
is invoked without --bloat option, it first finds all file-level
dependencies (something like "rpm -qaR |grep ^/"). This requires
a separate pass. The list of file-level dependencies is saved into
"reqfiles" global variable. And on the second (normal) pass, the
function usefulFile() is modified to check the "reqfiles" variable;
that is, it should keep a file in the file list if it's been required
by some package in the repo.
(Unfortunately, this patch does not solve all of the problems
I want it to solve; we have separate repos for i586 and noarch --
inter-repo file-level dependencies cannot be resolved this way.)
- Updated 'apt-get install' algorithm for versioned dependencies:
+ fixed wrong usage of ScoreSort condition introduced in previous release;
+ added explicit check if any package satisfying versioned dependency is
already installed or selected for install; in this case, apt-get will
not try to install any other package.
This fixes two problems:
1) Wrong usage of ScoreSort condition. ScoreSort sorts descending,
not ascending. Thus, previous patch assigned wrong score for already
installed packages.
2) Explicit check for already installed packages. If any package
that satisfies versioned dependency is already installed, nothing
at all should be installed (even if better versions are available).
- Updated my previous patch for versioned dependencies, which was half-way
wrong and incomplete. For versioned virtual dependencies like python=2.4,
'apt-get install' will always select real package with the best version
(which is python-strict#2.4.4-alt8, as for now)
My previous versionmatch.patch was half-way wrong and/or incomplete.
The problem was that pkgCache::VerIterator::CompareVer() does not
do full-blown version comparison, but rather something strange
(see apt-pkg/pkgcache.cc).
I also noticed that, while TryToInstall() does use Fix.ScoreSort,
TryToChangeVer() does not, which is probably wrong.
The solution is as follows:
1) pkgVersionMatch::FindAll() does not sort versions any longer;
it does not have sufficient information, such as Cache and Fix,
to sort the versions.
2) TryToChangeVer() calls FindAll() instead of Find() and uses
Fix.ScoreSort to sort the versions. If Fix.ScoreSort returns 0,
it also tries Cache.VS().CmpVersion(), which is the right way to
reach rpmvercmp().
Also updated 'Selected version ... for ...' diagnostics.
(old result and message)
$ ~tmp/build/aptbox/apt-get --dry-run install python=2.4 2>&1 |grep ^Selected
Selected version 2.4.4-alt8 for python
$
The result was wrong, because I have a better version,
which is 2.4.4-alt8.1.
(new result and message)
$ ~tmp/build/aptbox/apt-get --dry-run install python=2.4 2>&1 |grep ^Selected
Selected version python-strict#2.4.4-alt8.1 for python=2.4
$
Update: also do not sort ascending and reverse the list, this is going
to break "stable sort" logic. Just sort descending.
Update2: actually make CmpVersion() primarily sort condition and
Fix.ScoreSort secondary sort condition. Fix.ScoreSort should not be
activated early, because e.g. for 'python-devel>=2.3' it is going to
select python2.3-dev, but I want python-dev#2.4.
