This requires the build system support VALAFLAGS. At least Meson and
Automake do.
Using -g is desired because it allows us to see Vala source files and
line numbers in backtraces when possible, falling back to generated C
code otherwise. Line numbers for generated C are almost always less
useful when debugging crashes.
I changed the definitions in package-notes to not do anything if
%_package_note_file is undefined. The other macros won't work if it is
not defined anyway, so this is quite natural. With this, undefining
%_package_note_file becomes the most comprehensive mechanism to disable
the feature. (Undefining %_package_note_flags still works so backwards
compat is preserved.)
The new mechanism will work once
https://src.fedoraproject.org/rpms/package-notes/pull-request/1 is merged.
But I don't think it is necessary to add a version requirement here, since
we're only providing the docs here.
This is already the default for ld.bfd, so this is effectively a no-op
for most packages. However, lld defaults different build-id algorithm
that the RPM build process does not support, so it needs this flag.
This flag can be overriden by setting the %_build_id_flags macro,
which packages could do if they wanted to use a more secure build-id
algorithm.
This config is to let libtool recognize that our 64bit variant of
%_libdir is actually on the standard/default library path, so libtool
doesn't think it has to be hard-wired as RPATH. This is proper solution
for libtool RPATH issues described in:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_removing_rpath
The libtool script/macros (new enough, v2.4.6+) honor this variable when
it isn't possible to detect the system-wide default library path. It is
e.g. able to parse /etc/ld.so.* configuration, but there's no info about
/usr/lib64 on Fedora.
So to not force everybody to do:
%configure LT_SYS_LIBRARY_PATH=...
... rather set this system-wide. This is low-risk change since
older libtool scripts don't use this variable, and really no other
tools should.
