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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Again, this is to improve 'buildreq -bi' support. See, file(1) is
so full of shit that, to determine whether a link is broken, it has
to read the link and stat its destination (instead of bare stat
on the link). This hardly makes any sense, but enables buildreq
to calculate self-dependency when the package is installed.
This is to improve 'buildreq -bi' support: 'type -t' will stat
absolute paths and buildreq will make self-dependency. Note
that in the next command PATH is nullified to avoid stat/search
for regular commands.
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.
Though the intersection check can be useful even for /usr/src/debug
(it indicates binary code duplication and/or poor dependencies between
subpackages), it is too noisy and can eat up quite a bit of output.
The same information is still available directly within the packages
or via contents_index.
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).
Note that 'sh -e' mode is unreliable when the last pipeline command
is non-simple command (such as while loop). So the script was somehow
failing on hardlinks and it went unnoticed. I choose to replace
pipe-to-while with a temporary file for now.
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.
This finally provides missing strip controls. Note that even with
STRIP_NONE, the file will be edited with debugedit. So there is no
way to bypass brp-debuginfo completely (and maybe we should tolerate
debugedit failures with STRIP_NONE). But there is also an advantage:
/usr/src/debug sources will be installed even for non-stripped files!
This is why sources are now associated with .debuginfo/src/"$f"
instead of .debuginfo/src/"$debugf".
It might seem that build-id links should be created in brp-debuginfo.
However, there are corner cases: in brp-debugino, it is not yet known
which files are going to be packaged. This might be a problem when a
few identical files or hardlinks are created under buildroot: it is
possible create a symbolic link to a "wrong" file which will not be
packaged.
The solution is create build-id links in find-debuginfo-files: the link
will point to the first packaged file with the given build-id. However,
note that find-debuginfo-files is not part of the install stage, and
should remain "reenterable" (so that e.g. rpm -bl can be executed
multiple times). This means that the script should not make assumptions
whether the links have already been created.
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
- debugedit.c: Imported from rpm.org.
- brp-debuginfo: Initial revision, replaces brp-strip.
- verify-elf: Do not descend into /usr/lib/debug.
- build/checkFiles.c: Skip /usr/lib/debug and /usr/src/debug for now.
- platform.in: Always use -g in %optflags.
