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.)
