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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The check for cycles introduced in 4.0.4-alt100.17-6-ga71e004 appeared
to be incomplete. For example, it fails to recognize a cycle in the
following example:
%package -n test
Requires: libtest = %version-%release
%package -n libtest
Requires: libtest-common = %version-%release
%package -n libtest-common
Requires: libtest = %version-%release
warning: util-linux: non-strict dependency on libblkid
warning: util-linux: non-strict dependency on libuuid
warning: util-linux: non-strict dependency on libmount
warning: mount: non-strict dependency on libblkid
warning: cfdisk: non-strict dependency on libblkid
warning: fdisk: non-strict dependency on libblkid
warning: libblkid: non-strict dependency on libuuid
warning: libblkid-devel: non-strict dependency on libuuid-devel
warning: libmount-devel: non-strict dependency on libblkid-devel
warning: util-linux-debuginfo: non-strict dependency on libblkid-debuginfo
warning: util-linux-debuginfo: non-strict dependency on libuuid-debuginfo
warning: util-linux-debuginfo: non-strict dependency on libmount-debuginfo
warning: mount-debuginfo: non-strict dependency on libblkid-debuginfo
warning: cfdisk-debuginfo: non-strict dependency on libblkid-debuginfo
warning: fdisk-debuginfo: non-strict dependency on libblkid-debuginfo
warning: libblkid-debuginfo: non-strict dependency on libuuid-debuginfo
Note that the right time for this check is after strict dependencies
are propagated, and also after debuginfo dependencies have been lifted.
%package -n test
Requires: libtest = %version-%release
Requires: libtest-common = %version-%release
%package -n libtest
Requires: libtest-common = %version-%release
%package -n libtest-common
Requires: libtest = %version-%release
Here libtest and libtest-common make a cycle, and the "test" package
requires a cycle. Naiive optimization against a cycle can simply
wipe out all dependencies: the dependency on libtest-common will be
optimized out, because libtest-common is already required by libtest;
likewise, the dependency on libtest will be optimized out, because
libtest is already required required by libtest-common.
%_deps_optimization is now treated as optimization level 0, 1, or 2
(the default is 2). Level 1 will make single-package optimizations.
Level 2 will additionally optimize dependencies between subpackages.
Note that checkHardLinks function is now removed. It was unclear
whether it was supposed to verify %lang attributes (returning non-zero
on error) or indicate if all hardlinks are packaged within the package.
It turns out that only a single package in our repo has
PartialHardlinkSets dependency:
$ cd /ALT/Sisyphus/files/x86_64/RPMS/
$ rpm -qp --qf '[%{NAME}\t%{REQUIRENAME}\n]' *.rpm |fgrep 'PartialHardlinkSets'
$ cd /ALT/Sisyphus/files/noarch/RPMS/
$ rpm -qp --qf '[%{NAME}\t%{REQUIRENAME}\n]' *.rpm |fgrep 'PartialHardlinkSets'
freeciv-common rpmlib(PartialHardlinkSets)
$
This probably means that freeciv-common has hardlinks with different
%lang attributes (which probably was supposed to be an error). So
the whole issue should be reconsidered. A leave XXX marks in the
code and suggest new PartialHardlinkSets implementation (however,
the dependency is not being added yet).
When pkg1 has strict dependency on pkg2, all other non-strict/virtual
dependencies on pkg2 will be reaped off pkg1. Note that the are subtle
cases: though I try to make something about merging dependency flags,
it is not always possible, as the dependency on pkg2 can be obtained
via a transitive chain. I see this being a non-critical issue which
is worthwhile to be mentioned.
Basically, if pkg1 has strict dependency on pkg2, the question
is whether pkg1-debuginfo should possess a strict dependency on
pkg2-debuginfo. The answer is "yes" provided that pkg1-debuginfo
is already dependent on pkg2-debuginfo (i.e. has new soname-based
debuginfo dependencies resolved to pkg2-debuginfo). This provides
an opportunity for dependency optimization between dependend
debuginfo subpackages.
The output now is like this:
removing 12 sources from rpm-debuginfo and adding dependency on librpm-debuginfo
removing 11 sources from rpm-debuginfo and adding dependency on librpmbuild-debuginfo
removing 13 sources from rpm-build-debuginfo and adding dependency on rpm-debuginfo
removing 14 sources from rpm-static-debuginfo and adding dependency on rpm-debuginfo
removing 20 sources from librpmbuild-debuginfo and adding dependency on librpm-debuginfo
removing 13 sources from rpm-build-debuginfo and adding dependency on librpm-debuginfo
removing 80 sources from rpm-static-debuginfo and adding dependency on librpm-debuginfo
removing 12 sources from python-module-rpm-debuginfo and adding dependency on librpm-debuginfo
removing 12 sources from rpm-build-debuginfo and adding dependency on librpmbuild-debuginfo
removing 35 sources from rpm-static-debuginfo and adding dependency on librpmbuild-debuginfo
The output is like this:
remove sources from rpm-debuginfo because it requires librpm-debuginfo
remove sources from rpm-debuginfo because it requires librpmbuild-debuginfo
remove sources from rpm-build-debuginfo because it requires rpm-debuginfo
remove sources from rpm-static-debuginfo because it requires rpm-debuginfo
remove sources from librpmbuild-debuginfo because it requires librpm-debuginfo
remove sources from rpm-build-debuginfo because it requires librpm-debuginfo
remove sources from rpm-static-debuginfo because it requires librpm-debuginfo
remove sources from python-module-rpm-debuginfo because it requires librpm-debuginfo
remove sources from rpm-build-debuginfo because it requires librpmbuild-debuginfo
remove sources from rpm-static-debuginfo because it requires librpmbuild-debuginfo
