- ...to avoid wasting memory on the relatively static data. We could
handle the rpmlib ds singleton behavior here too but it would change
semantics. Ponder about it later...
- Would be nicer to have rpmdsMerge() freeze on return, but that
gets called in loops so we'd be doing a whole lot of huffing and
puffing recreating the pools on each entry.
- Allow rpmdsCurrent() to share the pool and id's of its "parent" ds
instead of having to repeatedly create and tear down entire pools
just for a couple of strings. Used by python bindings for rpmds
iteration so we'll want to be reasonably efficient.
- For now, rpmdsSingle() and rpmdsThis() always get a private pool,
wasteful as it might be, but at least now we can freeze them.
- Always push dependency names and versions into string pool (private
for now). This is terribly wasteful for single ds items, even more
so for rpmdsCurrent() but to keep the initial switch-over changes
to minimum we'll deal with those later.
- While we freeze the pool for ds data from headers, single ds items
are on purpose not frozen for now, due to interactions with
rpmdsCurrent() and rpmds merging.
- Eliminate no longer needed rpmdsDupArgv(), we're now just copying
a bunch of integers around. Sanitize rpmdsMerge() now that we can:
realloc and shift the data instead of recreating all of N, EVR
and Flags.
- Using rpmtd iteration for this is slow and stupid as we keep
pointlessly re-re-re-re-re-validating the tag type and indexes.
- Change argument order to source -> destination
- Move to rpmtd.c where it belongs and make public with a decent
name. Not sure if this is the kind of an API we really want to make
public but ... at least for now it'll do.
- Eliminate numerous repeated direct accesses to [o]ds N, EVR and Flags,
instead use getter functions and local variable for ods name which
does not change.
- Eliminate numerous repeated direct accesses to [o]ds N, EVR and Flags,
instead grab them into local variables through getter functions as
needed: on entry for ods which doesn't change, for ds in the loop
as we're changing ds->i here.
- The EVR comparison is a distinct operation of its own: rpmdsCompare()
looks at the other properties, EVR comparison is done if needed.
Doesn't affect speed or functionality, but cuts down on the
big number of local variables and has the nice side-effect of
making the xstrdup() allocations local within rpmdsCompareEVR()
- Eliminate numerous repeated direct accesses to ds N, EVR and Flags,
instead grab them into local variables through getter functions
as they are needed. Besides making it easier on the eyes, makes the
function safe(r) wrt illegal iterator values etc.
- Eliminate numerous repeated direct accesses to ds N, EVR and Flags,
instead grab them into local variables at entry. This also makes
the function safe illegal iterator values (ie calling when iteration
not started), previously the bounds were not checked.
- Always push base and dir names into file info sets string pool,
whether private or shared. For basenames, this can save significant
space even in a private pool, for dirnames private pool is moot
as the names are already unique, shared pool is quite another story.
- Adjust fpLookupList() to take a pool and id's as arguments.
- This introduces a fair amount of overhead, so things will be somewhat
slower until the transition to pool id's is (more) complete. Sometimes
things have to get worse before they get better... Other than that,
this should be entirely invisible to callers.
- Grab and validate the file triplet before placing the data into the
file set. Other than making it more explicit, doesn't matter right
now but we'll need this shortly.
- Refactor the file triplet sanity check into a generic indexed triplet
sanity check (and notice there was an error in the previous index
range checking, duh)
- Apart from the index range fix, shouldn't change any actual functionality
- Split file info generation by mandatory/optional data: every file info
set has the file triplet information, but all other data is optional
depending on the create flags. No functional changes.
- Being able to create just the core file triplet and fully populate
later might be useful for checkInstalledFiles(), but we'll see about
that...
- Removes the last use of our former simple, stupid and slow caches
- For now, use a per-fi pool for this just like the previous caching
did. Memory use is slightly increased but its faster than before,
to reap the full benefits (memory and otherwise) we'll want a
per-transaction pool for these, to be added later.
- With the string pool we dont have to worry about overflowing the
indexes so we can lump all this relatively static data into one pool.
Because rpmsid's are larger than the previous cache indexes, we'll
loose some of the memory savings, but then the pool is faster on
insertion, and we'll only need one of them so...
- The misc. pool is never freed, flushed or frozen so it'll "waste" memory
throughout the lifetime of a process (similarly to the previous caches)
but its not huge so .. ignoring that for now.
- Very few packages have RPMTAG_FILECAPS at all, and the memory saving
for those that do is so marginal it hardly matters at all. At least
for now, dont bother.
- Returning structs by value is a bit icky, pass in a fp pointer
for fpLookup() to fill in instead. This leaves the actual return code
free for handling errors (but ignoring that for now as we always have)
The other option would be always mallocing the return, and we dont
want to do that...
- Shouldn't change any actual functionality.
- While harmless, having to count on one and act on another iteration
gets expensive when there are lots of labels specified. Especially
as the iterator initialization can already load the same headers
multiple times, sigh...
- Partial NEVRA labels cannot be reliably parsed, the various combinations
need to be figured out by trial-and-error. The rpmts layer doesn't stand
a chance of getting it right so move it to rpmdb layer. This doesn't
make the process any less stupid, but at least we get correct results...
- Fixes iterator count when arch is used in a label and more than one
arch variants of a package are installed. Previously iterator count
could be more than one despite actual iteration only hitting one
match, as the arch RE match was added after already initializing
the iterator.
- Also fixes various pathological cases:
- If a legal arch was part of name, version or release (stupid but legal)
we misinterpreted it for arch and failed to find the package.
- If a package with unknown architecture was installed (with --ignorearch)
we could not remove it by its arch as we relied on rpmIsKnownArch()
- Missed opportunity in commit 1a3a4089def9b00790eeebd6f931c99a03a3d44b:
removed packages have already gotten fingerprinted so there's no need
to redo that here.
- Speedup depends on the transaction and is by no means enormous,
but on my testcase of a largish erasure transaction this shaves
off circa four percent of the cycles spent in (re)hashing the
basenames.
- We've been calling matchNetsharedpath() for every single file in
the transaction regardless of whether %{_netsharedpath} is set or
not (and almost always it is not), meaning lots of pointless
strlen() calls and in case of erasure, rpmfi iterations performed.
Not exactly a massive speedup but a speedup nevertheless.
- Avoid repeatedly calling rpmteGetFileStates() for every file processed
- Avoid rpmfi iteration, use a good ole for-loop and index-accessors
- Dont bother looking up symlinks for skipped files
- Eliminate rpmfi from the latter loop, its not used for anything there
- Not that this is going to show on wall-clock times, the cycles saved here
are going to get very much lost in the noise of more expensive things.
- If the replacing %config file is a %ghost, then we'll just leave whatever
might be on disk alone.
- OTOH in the opposite case we probably *should* take backups, if the
file exists on disk and is differs from the new non-ghost (but
currently we take never take backups for %ghosts)
- Similar to commit 80ee39da35544253cab12abd54af8754335ac945: this
started leaking at commit 3f996a588a
as rpmfiFNIndex() returns malloced memory. Refactor the lucky 13
return points into one, allowing cleanup at exit.
- Previously we'd turn all but FAILED results into "OK" after first
check, now we return the real value. And perhaps more importantly,
no longer try re-verifying previously failed headers in vain.
- When we get rpmdb hits on files from packages that are to be removed
in the same transaction, we can use its existing file info set
to grab base- and directory names to avoid bunch of headerGet()'s
and consecutive rpmtd manipulation. In theory this should speed up
transactions where lots of packages get removed, in practise not
really - the big cost here is in loading the headers from db in the
first place, despite not being really needed.
- When we get rpmdb hits on files from packages that are to be removed
in the same transaction, we can use the exisiting file info set
to avoid constructing a new temporary one. Might be measurable
in large updates.
- Change the hashtype name to something else, its no longer a plain
int hash. Still needs double definition as its not contained in
a single source (might want a wrapper similar to rpmal), but
slightly more contained now than the previous intHash definition.
- This opens up some new possibilities, to be taken advantage of
in later commits.
- This is really private to rpmdb.c (other than being exposed in
the struct definition in backend/dbi.h, sigh), let it live its
own life there.
- No functional changes here, just cleaning up a bit for next steps.
OTOH we could now cache the actual result, not just success... but
leaving that to another time.
- The cases in handleOverlappedFiles() and handleInstInstalledFile() only
differ by presence of "other file state", unify the copy-paste code
to helper function and comment a bit more.
- Push all the color fiddling into the helper, eliminating loads of
unnecessary rpmfiFColorIndex() calls in the common case. Also gives
us a single point of control for the color-conflict behavior.
- This is not supposed to change any behavior at all, just refactoring...
- Kinda similar to commit 12322bad67 but for
conflicts among the added set: grab the conflict filtering flag once
outside the loop and use to determine whether to report detected
conflicts or not. Doesn't change actual functionality.
- Rpm cannot currently *correctly* deal with directory symlink changing
to a directory through updates, detect early and abort with conflicts
instead of proceeding with known-broken results: previously these
would seemingly succeed but without actually doing the requested
changes, and leaving orphans on the disk. Far less evil than the
directory replacement failure but incorrect anyway.
- Same %pretrans wackiness as with directory replacements applies here.
- Adjust test-suite to match the new behavior.
- It's possible there are packages that have been relying on the former
broken "success" results, so this might need further fine-tuning...
- Rpm cannot currently deal with directory changing to something else
through upgrades. Until now we've barfed up an ugly error in the
middle of transaction, leaving partially installed broken junk behind.
It'd sure be nice to be able to actually handle this some day, but
until then detecting and aborting early is a far better option than
the former behavior.
- There are some "only in rpm" level bizarre quirks here: packages
can work around this limitation by using a %pretrans scriptlet,
which runs before the conflict detection. But this means a possible
test-transaction (as done by eg yum) will still see the conflicts,
as we obviously dont want to run disk-modifying scripts on
test-transaction. So when looking at these removal conflicts, we filter
them out on test-transaction IFF the package has a %pretrans script
so there's a chance it might actually fix the conflict when we get
to it in a real transaction. Obviously %pretrans from any package
could in theory fix such issues, but as this is evil enough as it is,
try to limit the damage... Without %pretrans, the only other option
to get around these is manual intervention.
- Unless the file does not exist on disk, we cannot determine the
correct action for config files and symlinks before we actually
check them. Those are also the only types that *can* result in
FA_ALTNAME/FA_SAVE action, anything else we can just create.
Besides making the logic a whole lot easier to follow, it also
fixes our remaining test-case failures. Who would've thought?
- Might be worth noting that this requires the pile of fsm fixes
from previous commits to work.
- When a directory is about to replace a %config needing backup,
we need to backup early as directories don't use a temporary
path, and fsmVerify() will remove the file before we get to
it in fsmCommit().
- We already have a carefully precalculated action decided for these
things, use that instead of bunch of arbitrary (except for osuffix)
conditions depending on several nasty hacks and hidden assumptions.
Doing so fixes stuff, who would've thought of that?
- Adjust test-suite expectations
- fsmVerify() never ever returns 0 for regular files because of
multiple hacks in how this all "works": on install, we skip stat()
but claim disk checked and file not existing, so fsmVerify() returns
early. Good thing it does too, as otherwise it would remove the
file we were supposed to be saving here. The actual %config backup
occurs in fsmCommit(): regular files are first installed with a
temporary suffix and at "commit" time we decide whether it needs
backing up or not (involving several other hacks...)
- rpmfiFNIndex() returns a malloced string since commit
11116a6786 but this wasn't taken into
account in commit 3f996a588a, causing
a massive memory leak on transaction preparations.
- Optimize the entry by avoiding rpmfiFNIndex() and lstat() until
really necessary, and use a central exit point beyond that so
we can free fn. Besides fixing the memleak, this gives a small
but measurable performance improvement on this rather busy path.
- Besides eliminating another copy-paste variant of the config file
digest calculation and comparison, this fixes the case modified
%config symlink gets silently erased. Unlike a regular config file,
a symlink does not contain a whole lot of carefully tuned data, but
if it's marked %config I think we should honor the %config file rules.
- Adjust test-suite expectations to match the new behavior.
- Similar treatment as in commit 9f9ed70e2d,
pay more attention to what kind of files we're comparing in each case,
add a little breathing room and extra comments.
- Handle the case where on-disk link is identical to the one in new
package in which case no backup will be needed, fixing two cases
of unwanted backups in the test-suite.
(similar to commit 7a50e9de80)
- Other than the on-disk vs new package change, probably doesn't change
anything yet, but prepares us for the next steps.
- Only return early in the cases where backup will NOT be needed.
Pay more attention to what kind of files we're comparing in each
case, add a little breathing room and extra comments.
- This probably doesn't change anything as-is, but hopefully makes
the logic a bit easier to follow and prepares us for the next steps.
- After commit 1845c1d711 erasure
no longer calls fsmCommit(), missing the backup step entirely.
Simply split the backup code to a function of its own and call
as needed. The details look somewhat fishy but what in fsm doesn't...
- When on-disk %config file contents match the contents of the new
package (such as config in old package was buggy, fixed in new
and admin worked around in the meantime) there's no point creating
a backup that's identical to what you already have. Note that
we create the new config anyway instead of skipping as timestamp
might have changed.
- Adjust test-cases to the new saner behavior.
- When packages share an identical file, we only need to create the
first one we encounter and skip it for the rest (reverse already
happens, and must happen, on erase). This has the benefit of
getting the timestamp to match the first file, which often is
also the last one to get removed. Also when lots of shared files
are involved (such as in multilib installations), this can give
several percents worth of speed gain as we dont unnecessarily rewrite
the same contents over and over.
- Commit 429b933b42 fixes the fd-leak
regression in rpm 4.10, but we already have code which relies
on the new behavior and segfaults with the former one. Adjust
rpmcpioClose() to the old behavior to get master tree back to
working shape. TODO: fix this properly some rainy day (oh and see
http://geekandpoke.typepad.com/geekandpoke/2012/08/likelihood.html)
- Verifying files against the originating, non-installed package can
be useful sometimes, eg if rpmdb is broken or cannot be trusted.
Of course such verification will give false positives on files that
were intentionally skipped during installation (nodocs, wrong color,
netshared...), that can't be helped.
- This restores the former behavior that was erroneously changed
in commit adbd484372 while "fixing"
an unhandled enumeration in the switch. Doh.
- As noted (but since then blissfully forgotten) in the commit message,
commit e696b409fe broke --badreloc
so its been broken since rpm >= 4.9.x :-/
- Transaction problem filter is only available during rpmtsRun() so
we have no clue whether bad relocations should be filtered or not
during rpmte creation. Instead of creating the problems at rpmteNew()
time, remember any bad relocations that were found and check +
create the actual problems (unless filtered) along with other
problems during rpmtsRun().
- Passing an "allow bad relocations" flag to rpmtsAddInstallElement()
would be a saner option but this is a back-portable way of handling it.
- For now there's no way to set this flag from packages so it doesn't
actually do anything, but it doesn't hurt anything either, allows
Suse & friends to drop one patch (greetings Michael :) and there
are might be some things we could use this for internally.
- At the time when the file list is being processed, we dont yet
have the slightest clue what kind of payload will be used for
for the archive or what limits it might have. Let the cpio code
handle its own limits checking, the build-side only needs to
worry about whether 32bit uints are sufficient for storing the
sizes in headers.
- 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).
- Refer to RPMTAG_* for rpmds tags, not RPMDBI_*. The values for these
are the same, only the "intended use" differs (RPMDBI refers to
rpmdb indexes) so this doesn't change anything in practise.
- dbtag cannot possibly be on obsoletes here, we need to look at deptag
instead. This thinko in commit 5f1ec21518
renders that whole commit useless. Doh.
- RPMFILE_EXCLUDE only exists during spec parse, and doesn't "leak"
into headers only because the file is, well, excluded to start with.
Unexport the internal-only bit and explicitly strip out any excess
bits from data going to header. The current 16/16 split is artificial
of course, RPMTAG_FILEATTRS is 32bit so there's plenty of room
for growing new file attributes, with internal-only adjustments
required.
- Eliminate RPMFILE_UNPATCHED while at it, this is a leftover
from Suse patch rpms which are no longer used anywhere.
Hi Panu et al,
Here's a small patch that changes the ordering used for putting
hardlinked files into the cpio archive back to lexicographical.
You might wonder what this is about. Well, old rpm-3 (and
also old versions of rpm-4, I think) already used lexicographical
ordering for files and hardlinks. When deltarpm was created,
it made use of this fact when "compressing" the file order
of the cpio archive into the so-called "sequence". Deltarpm
can deal with "out of order" files, but in that case it needs
to reset the compression, which leads to really long sequence
strings.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- BDB wants to use mmap() for its environment by default, but not
all (file)systems support this, as pointed out by Daniel Drak.
However env->open() can return EINVAL for a number of reasons,
require all the fallback reasons to be system level errors to
differentiate from "logical" errors such as incompatible flags
to (possibly pre-existing) db environment, in which case we better
just error out.
- The only remaining use for rpmts here was grabbing NODIGESTS
from rpmtsFlags(). Pass the tiny little piece of information
as an argument for the one place needing it and rip all the
now unused related goo.
- Most of fsm doesnt need the actual transaction set for anything "real"
and dragging it around as a mere statistics collector seems
pretty dumb. If we want better statistics, we better come up with
a saner way to gather them.
- Package building has no associated transaction or ts members,
this was all just fake-up kludgery to work around the way how
fsm used to work. None of it relevant now, kill kill kill.
- Determine the need for reverse iteration based on fsm goal
- Everything else was just using rpmte to get to its file states,
eliminate the intermediate ping-pong by passign the file states
around directly. Makes the thing that little bit less silly.
- Ghosts are never backed up, and the whole business is irrelevant
for package building. Use fsm goal instead of rpmte mode to
determine what to do, rpmte in build code is nothing but an ugly hack.
- rpmfs is such a low-level construct it doesn't need to know anything
about the upper layers. Gather the necessary bits of info in the
sole caller instead and pass only whats needed to rpmfsNew() to
enable creating a filestate item without having rpmte/header at hand,
which we'll be needing in the fsm shortly.
- This whole thing probably isn't needed anymore, but for now just
lift the FA_SKIP/FA_COPYOUT setting to rpmPackageFilesArchive(),
allowing rpmfsSetAction() to become properly internal-only function.
- Trim out unnecessary now unnecessary librpm internal includes
from librpmbuild code
- This allows much nicer handling some common scenarios such as
upstream pre-releases where the pre-release version would normally
appear newer than final release, eg 1.0-rc1 vs 1.0. Previously this
required mapping the pre-release tag into the release tag to achieve
desired sorting, with tild this becomes simply 1.0~rc1 < 1.0.
- Add a rpmlib() tracking dependency to prevent older rpm versions
from getting confused with packages relying on the new behavior.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Fix oversight in commit 9fb81eac0bcd239e46459f72916099f1adfc5cb9:
rpmdsMatchesDep() works on provides, but obsoletes are matched on
package name so we want rpmdsNVRMatchesDep(). rpmdsMatchesDep()
"worked" as the implicit self-provide is always at the 0 index
on packages created by modern rpmbuild, but this isn't really
guaranteed: very old V3 rpms can have something else at the
first index, and ditto for non-rpmbuild created packages.
- Thanks to Michael Schroeder for pointing this out.
- Now that there are no more failing parts requiring return codes,
change + rename fsmSetup() into a more regular fsmNew() construct,
returning newly "instance" of fsm and similarly fsmTeardown() ->
fsmFree() to free the thing.
- There's no real need to allocate this stuff on heap, but doing
so makes life actually simpler for the three callers and makes the
whole thing more consistent with common practises in the codebase.
- Checking missing links is only relevant for install, lift the
code to separate function and call from the install-case only.
- Freeing data while checking seems like a dubious "optimization"
but to keep changes minimal, leaving that as it is now.
- When writing, archive finalization can write further data into
the payload (eg cpio trailer). We need to be able to fish the
final archive size *after* closing it, otherwise archive size
will be off by trailer size.
- Add new rpmcpioFree() function which simpy frees the archive struct,
calling rpmcpioClose() in the process if it wasn't already done.
- This also simplifies the error code gymnastics in fsm: we need to
free the resources whether error or not, which rpmcpioFree() allows
us to do. And for writers, calling rpmcpioClose() only needs to
be done if earlier parts were successfull, so we dont need to worry
about masking a former error code when calling it.
- Only install and build have an associated archive, and this can
be just as well handled as a local variable, passing down as
argument to the handful of places needing it.
- Error handling looks a bit fishy but that's not exactly new issue...
- The mapping index is the same for build + erase, but different
for install and so is the return code mapping. By doing this
inline where the action is we avoid having to fiddle with
mapped return codes for the exit case.
- Besides simplifying the common path everything takes, this removes
the need to map error returns back and forth when we can just
detect the end of payload directly in the loop and break out.
- There's zero need for the rest of the code to know or care about
dnl iterator, just pass the file info- and state sets to
fsmMkdirs() directly and hide the otherwise unused iterator
business there.
- Besides being a bizarre name for "some extra initialization" work,
fsmCreate() was full of redundant goo, including a rather complex
way of mapping a zero return back to zero in case it really was
zero .. or something.
- rpmPackageFilesInstall() is the only case where this needs to occur,
move it there instead of yet-another goal-dependent piece where it has
no business being in the strangely named fsmCreate()...
- Except for expandRegular(), all notification occurs from the three
main worker functions. Pass as an argument for the lone special
case, the other noticy already have the psm as their own argument.
- fsmCommit() does not advance the archive or anything else, so
this was simply issuing the same exact notification that we
just did from rpmPackageFilesInstall().
- Only handle %missingok in the cases where it actually applies,
and additionally handle missing %ghost which is not an error
either. Dont log anything for these non-errors.
- Unify the error handling for files and directories, makes life
simpler as they dont differ by that much.
- Log real failures as warnings instead of silencing them to debug
spew, users will want to know if something that was supposed to
be removed was not (say, a file with immutable attr set).
- Add comments for further work on this area.
- In their previous life these breaks applied to a switch-case but
now they end up aborting the loop on first successful removal, causing
everything but the first file/directory of a package to be left behind
on erase. Fixes the previously unnoticed regression from commit
1845c1d711.
- For practical purposes, the "content" of a device node is its
minor+major number, if those differ the files are very much
not the same and thus cannot be shared.
- Two files (or directories) cannot be correctly shared if their
permissions differ, even if the content is identical: either
file will end up having wrong permissions, depending on installation
order. This means a package can among other things silently
eg relax permissions of eg security sensitive directory (accidentally
or intentionallY).
- We now require exact match of user, group and entire file mode
(previously only the file type part of mode was tested)
- Packages having file conflicts with itself may seem absurd, but
directory symlinks (such as /lib being a symlink to /usr/lib)
make this entirely possible. This makes us catch and abort early
on these cases instead of silently overwriting the self-conflicting
files, potentially with disastrous results.
- Packages having file conflicts with itself may seem absurd, but
directory symlinks (such as /lib being a symlink to /usr/lib)
make this entirely possible. This makes us catch and abort early
on these cases instead of silently overwriting the self-conflicting
files, potentially with disastrous results.
- The final pre-requisite to handling file conflicts within a package:
with this we're no longer tied to the single index per rpmfi. This
is not supposed to change anything yet unless I screwed something up.
Also goes to show that a semi-iterator interface for something
that really needs random access only gets in the way rather than
helping...
- Further preliminaries to handle file conflicts within a package.
- These are internal-only interfaces so we can just change without
bothering with compat wrappers.
- Preliminaries for handling file conflicts within a package:
Using rpmfi's self-iterator limits access to the file info to
one caller at a time, in order to self-file conflicts we'll need
to be able to access the same rpmfi at different indexes simultaneously.
- As these are public API's, add compat wrappers for the self-iterator
use (although AFAIK nothing except rpm itself uses these)
- Turn the strange negated condition around: when dealing with
config files test for it directly. This way, all the special
cases are handled first and normal cases fall through the if-jungle
to exactly one case of rpmfsSetAction(fs, i, FA_ERASE). Makes
the logic more obvious, at least to me.
- handleOverlappedFiles() only needs the file name in a couple
of relatively rare special cases. Constructing the fn more
expensive than other rpmfi-calls, dont bother unless actually needed.
- Previously this would return a pointer to an internal per-rpmfi buffer
whose contents get silently overwritten on each call to rpmfiFNIndex(),
making it unsafe for unsafe for random access for more than one
active caller (such code does not currently exist in rpm though)
- Make rpmfiFNIndex() always return freshly allocated memory, and adjust
the rpmfiFN() iteration wrapper to free and realloc the internal
"buffer" on each call. It's a wee bit slower than before but it's
not called *that* much, and if needed there are ways to optimize it.
- Similar to commit 9fb81eac0b but
on the to-be-installed set: obsoletes should only be matched against
package names, not any provide or file names. Hasn't really mattered
previously due to the way its called, but since commit
05487d9a3f I guess it started to matter.
It's more correct this way anyhow, and should fix RhBug:810077.
- Since rpmal only knows about provides, we need to handle obsoletes
as a special case and filter out matches on provide names different
than the matching package name.
- Undo the ancient broken fix for RhBug:71996 from commit
9e06e3b8ca76ae55eaf2c4e37ba9cac729789014: instead of disabling
the check, pass in the correct upper range which is entirely
different from everything else for the region trailer tag.
- Fixes CVE-2012-0815
- Non-existent region tag is very different from existing but invalid
one - the former is not an error but the latter one is, and needs
to be handled as such. Previously an invalid region tag would cause
us to treat it like rpm v3 package on entry, skipping all the region
sanity checks and then crashing and burning later on when the immutable
tag is fetched.
- Refer to REGION_TAG_TYPE instead of RPM_BIN_TYPE wrt the expected
type of region tag for consistency and clarity, they are the same
exact thing though.
- Should unify these damn copy-slop check one of these days, sigh...
For now, settling for the easily backportable approach.
- Fixes the other half of CVE-2012-0060
Panu Matilainen