This is just plain patch, but generates backups suffixed by patch
ordinal (NOT patch number) for the benefit of gendiff. Hence the name.
Thanks to Per Øyvind Karlsen and Neal Gompa for inspiration, input
and patch suggestions in PR#109 and PR#110.
The quilt backend has been using %1 but that only worked due to flaws
in the macro engine: automatic macros are not cleared for
inner callers, they can only be overridden. This makes the the
scm backend %1 argument real to begin with, and adds another one:
the patch ordinal might be useful for some purposes.
It's tempting to use %1 and %2 from %apply_patch - we're only passing
them along unchanged, right? Well, it's just that rpm does not expand
arguments of parametric functions, so those %1 and %2 would refer
to themselves within the called macro. Gotta love it...
Since commit 68bddc353a we're initially
creating the signature header with estimated values, and if you're
unlucky enough to have the estimated and actual size on the different
sides of UINT32_MAX boundary, the resulting package will have the main
header off by eight bytes, making it unreadable by rpm (RhBug:1405570)
Always reserve a little bit of space in the signature header so we
we can maintain the overall size constant regardless of whether 32- or
64-bit tags were used by using a smaller "padding" with 64bit tags.
Commit 6d2124ae90 broke headerCopyLoad()
which doesn't supply the size ... because it doesn't know it. Handle
zero bsize in headerImport() by parsing the supplied blob early and then
do it again on the copied data. This also depends on commit
7c6b9d057c.
The ondisk-size is already there in pvlen so this is completely
redundant. The uc argument is only used for verifying whether
caller expectation of the size matches, and that is made again
optional here as well.
Versioned shared libraries typically have several symlinks pointing
to them directly and indirectly. When %_build_id_links is set to compat or
separate this causes bogus warnings about duplicate build-ids.
It looks commit bbfe1f86b2 intends to skip
symlinks since it filters on S_ISREG(), but since uses fstat()
on already open()'ed file it ends up stat()'ing the symlink target.
Flip stat() + open() around and use lstat() instead to fix it.
Some tests running under fakechroot started failing because scripts tried
to execute /usr/bin/rm but inside the testing chroot /usr/bin and /bin
aren't linked. Just symlink testing/usr/bin to testing/bin to simulate
a unified /usr setup.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
Programming errors like SIGSEGV and SIGBUS need to get through no
matter what and blocking them is undefined behavior anyway.
The odd man out in this list is SIGTSTP which is just otherwise useful
and not harmful since the process can be continued afterwards.
This includes (but not limited to) rpmtsRun() during which the accidental
ctrl-c no longer aborts the whole dang thing. This could've of course
been done without all the other recent signal infra too, but now that it's
all neatly (yeah, right...) wrapped inside rpmsq instead of being littered
all over town its nicer to do.
This could've been done in commit 45d63715039d19fc2bd4be14229d37561fe0bd16
already of course but should there be regressions (my oh my!) this makes
it easier to bisect.
For rpm's purposes blocking all signals and restoring to previous
status is the only necessary operation, make this part of the
official API to make it available everywhere and replace rpmdb
internal signal handling code with it.
Noteworthy points:
- The block/unblock operation is reference counted so these can be
nested to arbitrary level without messing up things, much like
the internal chroot API.
- The rpmdb code used to remove rpmsq signals from the blocked mask, but
blocked should really mean blocked, really. The pending signals will be
delivered when unblocked and there's no need for us to mess with it.
- Unlike the rpmdb variant, we now Run rpmsqPoll() *after* unblocking
the signals. This actually matters now because rpmsqPoll() honors blocked
signals since commit 07620f4ae7.
This is more in line with how "normal" signals behave - if a signal
of the same type is already pending then the subsequent signals of
that type are dropped.
Queued signals might get processed much much later than they arrive,
and almost anything can happen in the meanwhile. Such as program
blocking signals before entering a critical piece of code, which
routinely calls rpmsqPoll() underneath since the code is not always
critical. Such as rpmdb iterator init/free - sometimes they're
called during harmless read-only query, at other times they're in
middle of transaction...
We always want the signal queue either enabled for the certain set
of signals or completely disabled, make the API reflect that and
make the switch "atomic", ie signal delivery is disabled while
changing state.
Perhaps more importantly, this allows changing signal handlers "offline",
so an application can set its own signal handler for, say, SIGINT
*in case* the signal queue is activated.
rpmdbCheckSignals() is a public function and it'd be trivial to keep
it but there are no known callers and its such a hysterical name that
lets just get rid of it while we're breaking the ABI anyway...
Copy the info contents on signal arrival, pass on to handlers during
poll round. There are some pointers in siginfo_t whose validity might
be questionable at the time we get it, but then those pointers like
address of segfault aren't exactly something to go poking at anyway.
The original rpmsq API is somehow backwards and upside down: it allows
overriding the handler when enabling the queue, but if the queue is
to be enabled for a signal, then the only possible handler for
it is the action that stores the signal in the queue. If you wanted
to have some other kind of behavior you wouldn't want to enable the
queue for that signal to begin with!
What applications need is the ability to override what happens at
signal poll, not arrival time - arrival time is at odds with the
whole queue notion. So introduce a poll function which runs the
handlers for caught signals, clearing them on the way. Add to that
the notion of default handler which is called if no custom handler
is set. Now this can be trivially used to replace the signal foobar
inside rpmdb and suddenly applications can replace the standard behavior
with a simple
void my_sigint_handler(....)
{
/* do foo */
}
rpmsqEnable(SIGINT, my_sigint_handler);
...and the custom hander will be called when a SIGINT has arrived
and the next signal polling round from rpmdb internals or whever
occurs.
rpmsqAction() is removed from the API/ABI here, but it's not as if
it ever was useful to anybody anyway.
Life's too short to keep worrying about ancient junk forever.
Even Hurd has this now, can you imagine? (Hurd was the reason
this was special-cased back in 2008)
There's little better way of tracking set of signals than a sigset_t
with its associated APIs. For one, this way we dont for example need to
loop through the table to see if a signal is active or not.
Note that This drops the "fancy" reference counting: calling rpmsqEnable()
with different handlers would increase the refcount but not actually change
the behavior, so the refcount means exactly what? The refcounting also
hasn't been used by rpm at all/in a long time, because whether its
active or not is tracked by the rpmdb code which is the only place
really knowing if its needed or not.
There's a standard C mechanism for cleaning up cruft at exit and
it's known as atexit handler. atexit() handlers do not get called
when exiting due to signal, but we're trapping the signals and calling
exit() voluntarily in that case so... for fsck's sake Sherlock.
This removes rpmdbCheckTerminate() from the API, the semantics
change incompatibly here and it makes even less sense after this.
It's a good time for this change since we're removing all sorts of
other goo out from the API as well.
Also rip out the previous workarounds from python side, RIP.
Commit 4c6e51e2c0 seems perfectly
sensible but managed to break rpmdb handles cleanup on signals,
ie the sole reason this mess of a code exists to begin with.
The reason that change did not work for rpm is it expects the surroundings
being sane when that's not the case: rpmdbCheckTerminate() removes
the entries from the handle lists before calling the destructor
functions, which would do the very same thing if you only let them. Not
mucking with the lists from left and right simultaneously makes things
work, what a shock.
The change seems logical enough, but that doesn't work when the surrounding
code is not. rpmdbCheckTerminate() is an idiotic API by yours truly
which must return non-zero exactly once because that's the signal
for the *caller* to call exit() (did I already say idiotic?)
Anyway, if it repeatedly returns non-zero rpm will exit() more than
once which at least glibc seems to take as "so lets exit already shall we?"
This reverts commit e5d3b9f682.
Trying to include AM_CFLAGS through a configure generated rpm.am file
doesn't really work because at the time automake runs configure doesn't
exist yet to process rpm.am.in. Just define the AM_CFLAGS substitution
inside the Makefile.am files themselves.
Rename rpm.am.in back to rpm.am.
Signed-off-by: Mark Wielaard <mjw@redhat.com>
The big block in rpmReadSignature() was only used for RPMLOG_DEBUG
level printing, obfuscating a rather important function needlessly.
Move all the data retrieval into printSize() and eliminate the
rather pointless return code based on fstat() success.
I think the reliance on bfd.h was a mistake. The code was lifted from
bfd, but should be totally independent (it just calculates a CRC).
Fix the type to be a normal size_t and include sys/stat.h (which was
included through bfd.h) to get the definitions of stat and chmod.
Ultimately there are exactly two possibilities here and we certainly
don't need a switch-case to handle it.
Thanks to Thierry Vignaud for pointing this out.
The switch-case is a leftover from times where different formats
sort of needed special handling in here, but RPM_NULL_TYPE is just
hysterical, headerGet() will never return such a data type. So
the whole thing is just moot.
Thanks to Thierry Vignaud for pointing this out.
Add reversed param to add(Single)Relation() for Supplements and Enhances
Also fix generation of reversed relations. As we generate all relations for
one package (p) at once they are all the latest on the other packages. So we
don't have to search through the list of relations there. But in the current
package the relation might have been added before others.
So we can check in package q if the relation is already there - using the
proper list depending on the direction. So we can't reverse by just switching
p and q before doing that.
CFLAGS is a user variable that software is supposed to honor but not
touch, that's what AM_CFLAGS and friends are for. rpm.am is
included by all our makefiles so that's a handy place to set defaults
centrally, do so by AC_SUBST'ing the rpm cflags into AM_CFLAGS there.
Commit c810a0aca3 changed the gcc flag
test to include a call to alloca() which at least on GCC 6.2 just
causes all the tests to fail with implicit declaration warnings
which are errors since we test with -Werror. Include <alloca.h>
to avoid the warnings and thus make the test functional again.
In array output (square brackets in query format) all tags data sets need to
have the same length. Single value tags may still be used. This patch fixes
corner case where they are only single value items and ones where arrays with
only one entries where treated as OK although they are not.
Panu Matilainen