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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This removes %post_ldconfig, %post_ldconfig_lib, %post_ldconfig_sys,
and %postun_ldconfig macros which were marked as obsolete by commit
da3de4082f back in 2008.
Terminate build if stripped ELF files are found. Usage:
%define _stripped_files_terminate_build 1
Formatting suggestions by Dmitry V. Levin <ldv@altlinux.org>.
FCFLAGS is modern replacement of FFLAGS for gfortran.
Details can be found in [1].
Modern Fortran applications use FCFLAGS instead of FFLAGS, so we have
them built without platform-specific and general optimizations.
As an example one may look how libgfortran is being built within gcc-9:
libgfortran/Makefile.in uses only FCFLAGS, not FFLAGS and mary other
applications follow.
[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Fortran-Compiler.html
It's always annoying when important information such as compilation
options used for build is not available in build logs just because
silent build rules are enabled by default.
Fix this for the case of build rules generated by configure
by disabling silent rules.
%EVR was introduced to be used in spec-files for intersubpackage
(strict) dependencies.
What if we write (when substituting %%EVR) E:V-R:D into dependencies
instead of the previously written E:V-R? Will the interpretation of
these dependencies by rpm change (when installing packages) in a good
or bad way in any cases?
The "dependencies" can be Requires, Conflicts, Obsoletes.
rpm-build already produces packages which include disttags (D), and
Provides in the form of E:V-R:D, and strict intersubpackage
dependencies of such form (Requires; generated automatically).
Intersubpackage Requires in the form "< %EVR" or "> %EVR" don't make
sense. So, the interesting cases this change can affect are:
* Conflicts of the form "< %EVR" or "> %EVR" or "= %EVR" (the last one
must be quite rare);
* Obsoletes of the form "< %EVR" ("= %EVR" makes little sense;
"> %EVR" looks strange because it's about obsoleting packages from future).
The rpm program can be "new" (which knows how to compare E:V-R:Ds with
disttags; since 4.13.0.1-alt5) or "old" (does not yet know it;
4.13.0.1-alt4 or earlier).
(rpm-build already produces "new" packages, i.e., with disttags.)
The "new" rpm program is considered to be the correct reference way to
treat disttags. According to it, the presence of a disttag in a < or >
dependency cannot affect its interpretation (whether it is satisfied
by another package). Adding a disttag to a = dependency would simply
make it more strict (and that's what rpm-build already does under the
hood for intersubpackage deps). So, E:V-R:D deps are OK for the "new"
rpm.
So, what about about the "old" rpm?
Let's pay attention to the cases where the "old" rpm behaves
differently from the "new" rpm.
Such differences can be demonstrated by running
rpminstall-tests-1.0-alt2.M70P.1 in a system with an "old" rpm and a
"new" rpm-build (that can produce packages with disttags).
Here are the interesting failed test cases without disttag in the dependencies
(like before the change made by this commit), i.e. with dependencies
in the form E:V-R written in Conflicts or Obsoletes:
* installable_dummyDisttag_with_conflGreaterEpoch (and similar ones)
$ rpm -qp RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1:zzz+777.66
$ rpm -qp RPMS/conflGreaterEpoch/noarch/conflGreaterEpoch-1-alt1.noarch.rpm --conflicts
dummy > 0:1-alt1
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/conflGreaterEpoch/noarch/conflGreaterEpoch-1-alt1.noarch.rpm
error: Failed dependencies:
dummy > 0:1-alt1 conflicts with conflGreaterEpoch-1-alt1.noarch
NOT OK (ALT#35930): this form of Conflicts is used to ensure that no
subpackages from different releases/builds get installed together.
* noninstallable_dummyDisttag_with_conflEqualEpoch (and similar ones)
$ rpm -qp RPMS/conflEqualEpoch/noarch/conflEqualEpoch-1-alt1.noarch.rpm --conflicts
dummy = 0:1-alt1
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/conflEqualEpoch/noarch/conflEqualEpoch-1-alt1.noarch.rpm
succeeds
NOT OK: this form of conflicts could be used to declare conflicting subpackages.
Here are the interesting failed test cases with disttag in the
dependencies (like after the change made by this commit), i.e. with
dependencies in the form E:V-R:D written in Conflicts or Obsoletes:
* installable_dummy_with_conflLessEpochDisttag (and similar ones),
$ rpm -qp RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1
$ rpm -qp RPMS/conflLessEpochDisttag/noarch/conflLessEpochDisttag-1-alt1.noarch.rpm --conflicts
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/conflLessEpochDisttag/noarch/conflLessEpochDisttag-1-alt1.noarch.rpm
error: Failed dependencies:
dummy < 0:1-alt1:zzz+777.66 conflicts with conflLessEpochDisttag-1-alt1.noarch
OK: dummy-1-alt1.noarch.rpm is from another build (if built with the
"new" rpm-build, it would include the disttag in Provides). This form
of Conflicts is used to ensure that no subpackages from different
releases/builds get installed together. The difference in behavior
with the "new" rpm is explained by that the "new" rpm cannot
(unfortunately) detect this subtle mismatch.
* nonobsoleted_dummy_with_obsolLessEpochDisttag (and similar ones)
(like the previous case)
$ rpm -qp RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm --obsoletes
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummy/noarch/dummy-1-alt1.noarch.rpm RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm
$ rpm -q dummy
package dummy is not installed
OK
* nonobsoleted_dummyDisttag_with_obsolLessEpochDisttag (and similar ones)
$ rpm -qp RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm --provides
dummy = 1-alt1:zzz+777.66
$ rpm -qp RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm --obsoletes
dummy < 0:1-alt1:zzz+777.66
$ rpm -i RPMS/dummyDisttag/noarch/dummy-1-alt1.noarch.rpm RPMS/obsolLessEpochDisttag/noarch/obsolLessEpochDisttag-1-alt1.noarch.rpm
$ rpm -q dummy
package dummy is not installed
NOT OK, but very improbable (the real name of the subpackage must be
the same as the obsoleted name of an older package, but the obsoleting
package is a different subpackage; so, it's improbable that one keeps
the old name of a subpackage, but wants to obsolete it with another
subpackage).
So, introducing this change to the %EVR value would make the new
packages be treated better by the "old" rpm; even the treatment in the
cases where the behavior is different from the behavior of the "new"
rpm is good (except for one improbable case).
Previously one who wanted to use only suffix from %_lib macro (without
'lib' prefix) had to either strip it with shell or try to guess it
from %_lib macro.
New macros allow to simplify library suffix logics in spec files:
* %_libsuff is always defined (to %nil on targets where %_lib = lib);
* %_is_libsuff is defined only on those targets where suffix
is not empty (it is useful for %{?...} expressions).
nproc(1) based approach has two advantages over /proc/stat based
calculations. Firstly, nproc(1) uses sched_getaffinity(2) and therefore
is not affected by /proc availability. Secondly, nproc(1) outputs
the number of processors actually available which may be less than
the number of online processors.
nproc(1) was introduced in coreutils-8.1.
glibc-2.26~154 changed behaviour of "getconf _NPROCESSORS_ONLN":
it now returns 2 instead of 1 when /proc is not mounted.
Change %_smp_mflags to use %__nprocs that is set to 1 when /proc
is not available.
gcc -frecord-gcc-switches adds .GCC.command.line section to each
generated ELF file. These sections have the same type (PROGBITS) and
flags (MERGE, STRINGS) as .comment sections. Like .comment sections,
.GCC.command.line sections are moved to .debug files by debugedit.
New implementation allows to invoke %make_build with a variable
assignments, e.g. LD_LIBRARY_PATH=.libs %make_build check.
A side effect of old %make_build was initialization of NPROCS
environment variable. New %make_build no longer initializes NPROCS,
but, according to specfile scan made by Igor Vlasenko, packages
in Sisyphus do not rely on NPROCS being initialized by %make_build.
Add a brp interface for checking contents of files in buildroot.
The initial revision of brp-check_contents scripts checks
for suspicious path names like /var/lib/run, complementing
the change introduced in sisyphus_check-0.8.43-alt1.
Some of %optflags options, -m* in particular, have to be passed to
assembler so that the output it produces would be consistent with the
output made by compilers.
The first two macros provide general mechanism for find-requires
and find-provides filtering. Any valid command or shell syntax can
be used - the command will be executed using "eval" within find-*
script. The implementation in %___build_pre is not particular
beautiful (as it uses here-docs), but there seems to be no easy
way to quote for eval yet.
The second two commands are built on top of the first: they use
sed as a filtering tool. The implementation is compatible with Fedora:
http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering
This introduces new macro %_configure_platform which will normally
expand to %_target_platform. However, for noarch packages, a special
version called %_configure_platform_noarch will be used, which will use
%_host_cpu instead of mock "noarch" cpu. Suggested by Dmitry V. Levin.
This fixes %configure failures like
checking build system type... Invalid configuration `noarch-alt-linux': machine `noarch-alt' not recognized
I enable ccache in my ~/.zshrc:
export GCC_USE_CCACHE=1
export CCACHE_DIR=$TMPDIR/.ccache
export CC=gcc CXX=g++
Now, under default rpm settings, ccache IS used with rpm, but the cache
directory is changed to ~/.ccache (since CCACHE_DIR is unset).
$ du -hs $TMPDIR/.ccache ~/.ccache
13M /tmp/.private/at/.ccache
39M /home/at/.ccache
$
These macros were added long ago. Now we use hasher for final builds.
It's okay to use default ccache settings for local builds.
