- This adds brutally simple utf-8 validation to spec parse & package
construction: all string-class tags in headers are checked regardless
of other tag semantics.
- Parse-time validation is optional via RPMSPEC_NOUTF8
flag, but package construction time is required as we want to
stomp RPMTAG_ENCODING to all packages that pass. What is always
optional is whether non-valid utf-8 strings fail the build, defaulting
to off (but distros probably want to enable it)
- Note we dont give a damn about the spec itself, only what ends up in
packages: strings can come from numerous other sources than spec
directly, and OTOH who cares if eg spec comments are non-utf?
- We'll need this to access any HWCAP_* bits for platforms that need it,
regardless of whether getauxval() is present or not. On glibc
systems this is likely to be equivalent, on others dunno (Solaris
appears to have sys/auxv.h header as well)
- The basic concept is not without merit but what was implemented here
has been stuck in experimental state in middle of two sorta conflicting
goals for four years now, and world has moved onward in the meanwhile.
The sepolicy part is better handled in the new selinux plugin, and other
action business belongs to packages (in the form of some trigger-like
scripts or such) rather than rpm plugins.
- Deleted here, but the sepolicy plugin functionality still needs
merging into the new selinux plugin...
- RPMTAG_COLLECTIONS left in place but tagged unimplemented as per policy
to never actually remove tags
This is needed as the new payload format for large files is not compatible with
rpm2cpio which basically just dumps the payload which happened to be cpio.
Use configure parameter --without-archive to not build this tool and get rid of the libarchive requirement.
glibc >= 2.16 provides getauxval(): a reliable way to retrieve a value
from the auxiliary vector. It doesn't rely on /proc filesystem.
Let's switch to it and get rid of /proc dependency.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- The mergesort() implementation we've carried all this time (even if
not compiled in when glibc is used) is one with the nasty BSD
advertisement clause, ugh. Better remove it late than never,
but let systems having mergesort() in their system libraries
(such as OSX) use it instead of qsort().
- This makes symlink timestamps reflect build-time instead of
installation time, similarly to everything else. On systems that
support lutimes(), that is.
- We dont have or care about microsecond precision, but this is the
more modern interface ... and on some systems there's an equivalent
that allows symlink timestamps to be set, but no such equivalent
exists for utime()
When configuring with srcdir != builddir the find-requires link would fail:
ln: failed to create symbolic link './autodeps/find-requires'
Do the link in the same way as find-provides with an explicit ${srcdir}.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- We wouldn't want anybody to shutdown (or reboot) the system while a
transaction is in progress, it's just that there hasn't been a whole lot
that could've been done about it. Recent systemd versions provide an API to
prevent shutdowns however:
http://www.freedesktop.org/wiki/Software/systemd/inhibit
- Add a simple plugin which, if enabled, tries to acquire a shutdown
inhibitor lock from systemd for the duration of transactionsd. This
could use better error handling and all... but its a start at least.
- Note that D-BUS is required, but only for the plugin, not (lib)rpm.
- VFY_VerifyDigest() has been deprecated since NSS >= 3.12 and for
a good reason too: with VFY_VerifyDigest() caller needs to painfully
enumerate every possible supported enc + hash combination, only for
NSS to revert the process. Use the saner VFY_VerifyDigestDirect()
interface instead and test for its presence in configure.
- This means we now require NSS >= 3.12 but as that's already 4.5 years
old and included in ancient beasts like RHEL-4, this doesn't seem
exactly unreasonable requirement. And then there's always beecrypt...
- Older NSS versions operate on global context, which can cause
all sorts of trouble when an API user tries to use NSS for their
own purposes: eg they might want to use NSS databases which is not
possible once we've initialized NSS with NSS_NoDB_Init(). Further
background on the subject at https://wiki.mozilla.org/NSS_Library_Init
- Use private private NSS context when possible (NSS >= 3.12.5) to
avoid such clashes, but keep support for older versions for now.
- NSS is a big and quirky monster for our needs but that's what we've
been defaulting to for the last years, and then there are those
certifications...
- Also default to external beecrypt even if --with-beecrypt is used
- Fixes fallout from commit f9c69f803f74bd458269c7a06def494ea63387e6:
running these tests with -Wstrict-prototypes causes all these tests
to fail as AC_LANG_PROGRAM() uses an incomplete prototype for
main() :(
- On gcc versions supporting -fstack-protector, not all platforms
support this feature, causing gcc to emit only a warning instead
of an error. Which then causes warning-spew on every compiled file.
Run all the supported flag tests with -Werror to turn the warnings
into errors, there could be other similar cases besides stack protector.
- Patch originally from Arnaud Patard according to this Mandriva commit:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages?view=revision&revision=448632
- Commit 4cb02aa928 asked to see
what breaks when mmap() is used, now we know: large package support
broke when enabling it. Could be fixed of course by eg adding
a size cap to the fsm part as well, but just doesn't seem worth it:
I fail to measure any meaningful performance improvement from mmap
usage in either case, and added complexity for what is close to
zero benefit just doesn't make sense... and various sources in fact
note the rpm usage (read through the entire file sequentially) as one
of the cases where mmap() is NOT beneficial due to mmap() high
setup + teardown cost + page fault speed (or lack of thereof).
- These are both "appears to have roughly the intended effect" level
tested, but I'm not really familiar with either bzr or quilt so
any further refinements need to come from people actually familiar
with these tools.
- This adds two main macros (+ bunch of helpers) to automate the
common case tasks in %prep:
1) %autopatch which automatically applies all patches from a spec
2) %autosetup which (optionally) takes care of it all, and (also
optionally) sets up a git/hg repository of the unpacked source +
applied patches as it goes.
- This should be considered a starting point only, there are various
things to improve. Eg we'd like to be able to make backups
with plain patch (based on patch number maybe) and at least with git,
we'd like to be able be (optionally) use 'git am' patching style
to preserve original authors + commit messages etc.
- A noteworthy point here is that as these are fully implemented as
macros, they are compatible with several older rpm versions as well.
- Lump glob.h and glob.c into rpmglob.c in all their g(l)ory libc
decorations and make everything static to stop overriding system
library symbols with our own glob().
Teach %prep and %uncompress how to handle 7zip tarballs, with
the mingw toolchain landing in fedora, this may be useful when
crossbuilding Windows sources compressed using 7zip (CxImage is
one such project).
- WTH are we compiling with -Wno-char-subscripts? This appears to have
been there since the dawn of times, and at least nowadays removing
it causes no new warnings.
- Re-enable -Wstrict-prototypes, either NSS headers have gotten fixed
or GCC has gotten smarter and no longer whines about broken
system headers.
- Unlike bz2 and xz/lz, zlib compression is not tracked by any rpmlib
feature and is part of the original package format really, zlib
simply must be always present.
- it's not rpm's job, not is it possible for rpm to know about
distribution/vendor names and preferences
- use build_vendor as the canonical vendor (affecting %{_vendor} default
and macro + rpmrc paths) unless overridden by --with-vendor=name
- Steps towards separating rpm-python from the main rpm tarball even
though developed within the rpm repository.
- Having the bindings in a separate tarball makes it simpler to build
them for different python versions, notably python 3 (RhBug:531543)
Panu Matilainen