Move cleaning the stat_s structs to fsmInit() (beginning of the loop instead of the end)
Drop freeing fsm->path as this is done in fsmInit() and fsmTeardown()
- For example, warn when building an x86_64 package that only contains 32
bit binaries.
- This should indicate to the maintainers that they might have gotten the
architecture wrong.
- Introduces 'archcolor' in rpmrc so we can map architectures to colors.
- Related: RhBug:713323
- Commit a25c3c7bac removed what was
supposedly a non-supported method of passing files as arguments
(instead of the normal stdin method) to rpmdeps. Turns out
rpmdeps is even documented to take files as cli args, and that's
how Fedora's %filter_setup macros are calling it...
- Allow files as arguments again, but in a way that doesn't cause
argvFoo() vs popt crash-n-burn.
Fseek() does not return a proper error code. This needs to be fixed before we can use it as most comprssed files do not support seeking and we need to be able to detect this reliably
Create cpio_t data type that holds the underlaying FD_t instance
Move padding and position handling and trailer generation into cpio.c
Use only one buffer in the fsm (merging the read and write buffer)
Replace the FSM_EAT, FSM_POS, FSM_PAD, FSM_DREAD, FSM_DWRITE states with cpio functions
Prepend "rpm" to the cpio function names
- rpmdb_dump, load, recover, verify, stat etc are useful at times,
but these are not. This also fixes build with internal db for
more recent versions of Berkeley DB.
- If the caller doesn't know the end pointer, we dont have a whole lot
of chance to come up with a reasonable one either. Just assume
the terminating \0's are there when end boundary is not specified:
when this happens we're dealing with relatively "trusted" data
anyway, the more critical case of reading in unknown headers does
always pass end pointers.
- While capping the end pointer to HEADER_DATA_MAX seems like a
reasonable thing to do (as was done in commit
f79909d04e), it doesn't really help
(bad data would likely run past bounds anyway), and it's not right
either: the pointer can be to a stack address, and the stack can be
near the top of addressable range, and ptr + HEADER_DATA_MAX can
cause pointer wraparound. Notably that's exactly what happens
when running 32bit personality process on 64bit system on Linux,
at least in case of i386 process on x86_64, causing all sorts of
breakage..
- Fix regression from commit 807b402d95,
the array gets passed as a pointer (how else would it work at all),
so despite having seemingly correct type, sizeof(keyid) depends
on the pointer size. This happens to be 8 on x86_64 and friends
but breaks pgp fingerprint calculation on eg i386.
- Also return the explicit size from pgpExtractPubkeyFingerprint(),
this has been "broken" for much longer but then all callers should
really care about is -1 for error.
- The test-root has a shell but rpm doesn't know about it, add a
fakeshell metapackage that provides it. Should come in handy for
other cases as well, up to now we've been limited to lua scripts only.
- Test that all the "normal" scripts get executed, in expected order
and with expected arguments, on install, upgrade and erase.
- This would've saved the rather embarrassing breakage with commit
274dbf557d at least, but better
late than never as they say... It also serves to highlight and
document the arguably broken arguments to %pre- and %posttrans
scripts (ie always 0)
- rpmteClose() will wipe out the file info to free memory, we only
should care whether we failed to (re)load the file info. This
thinko in commit 06a2f1269b
broke %posttrans scriptlets (and without commit
274dbf557d, %pretrans in other
circumstances), whoopsie *blush*. Now, off to write a test-case
for our scriptlet behavior...
- Despite commit cef18c9480, we'd still
end up freeing the file info sets via rpmteClose() while going
through the test-transaction packages. This together with commit
06a2f1269b caused install failures
on packages which have %pretrans scriptlets, if a test-transaction
was first performed on the same transaction set that gets used
for the "real" transaction as well. How wonderfully obscure...
- This is stupid... only librpm and librpmio actually need the bump due
to ABI breakage, librpmbuild and librpmsign are unchanged and could
use just a revision bump. But just incrementing the revision (or age)
would set us on collision course with maintenance updates to 4.9.x.
Then again its not like you can actually use librpmbuild or librpmsign
without also linking to librpm(io) so from everything needs rebuilding
anyway. This all also pretty much makes the whole libtool library
versioning a bit moot. Bah.
- "pure install" like 'rpm -i' never removes anything (long-standing
behavior that we dont want to change), but that causes us to allow
installing obsoleting packages without removing what they obsolete,
which in turn causes errors on verify. Not good.
- This (together with commit 9fb81eac0b)
makes obsoletes behave like conflicts in such a case, preventing
the inconsistency from taking place. Also verify will now whine
on all the involved packages on inconsistencies.
- Obsoletes should only be matched against package names, not provides,
or file names for that matter. This hasn't really mattered so far
due to the way rpmdbProvides() gets called currently, but there's
a missing case that requires this...
- '5' in verify stands for digest nowadays, keep the md5 reference to
explain why 5 is for digest though (related to RhBug:804049)
- In --dump query everything relates to files, refer to the attribute
in question ie 'digest' instead of 'filedigest'
- For non-hashed mode, dump the full NEVRA string. This might break
programs that are parsing the --percent format, but such programs
almost certainly need adjusting for the added erasure progress anyway.
- For hashed mode, show package NEVR instead of just name. Otherwise
somebody will sooner or later file a bug on "confusing output"
as it might seem it's removing what it just installed in upgrade-mode.
Full NEVRA would be better still but screen estate is tight as it is...
- Also get rid of headerFormat() call here, use RPMTAG_NEVR(A) extensions
instead.
- Commit 70f063cb77 accidentally
changed lua's base64 encode/decode interface too, ugh. Dangers of
search-and-replace... Only the function name string exported to
lua matters but renaming the internal functions back as well
for naming consistency.
- Grab the uncompressed payload size from header and compare number
of bytes copied to that for exit code. Previously, truncated
payloads could have returned with success. This also fixes the
exit code for large payloads (RhBug:790396)
- Files can be (much) larger than INT32_MAX, change the return
type to off_t and fix + simplify the calculations. Fixes the other
half of RhBug:790396 and makes ufdCopy() usable for other purposes too.
- Presumably the rpmrc internals still need the magic table tennis
but nobody else should want to mess with this, reconfiguration
for another (build) arch is done through rpmReadConfigFiles().
- The call to rpmSetTables() from rpmbuild is simply redundant for
all I can tell, it gets called from inside rpmrc/config processing
with the same values and the extra call here never changes anything
as the tables have already been set through rpmReadConfigFiles()
whether building for several targets or not.
- The number of entries is well know, allocate the entire list at
once and set instead of appending one by one. Also cures a leak from
created tuples not being decref'ed before - list set steals the
reference whereas append requires an additional decref to transfer
the ownership to the list.
- We know the array size beforehand, allocate the entire array
at once and set the elements instead of appending one by one.
This is (an obvious) and well-measurable, if not a huge, win.
- Various tools expect to get the full package list, not just those
that would actually be built. There are of just as valid reasons
for only wanting the packages that would be built, but we need
to make this caller specifiable, just changing the behavior breaks
existing tools unnecessarily. Add reminder comment why the thing
is the way it is...
autotools dependency tracking isn't generally useful in rpm builds;
disabling it results in cleaner build logs and possibly slight build
speedups.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Florian Festi