- In the package/transaction related things the strpool is more of
an internal implementation detail than an end-goal in itself, move
string pool related interfaces of rpmts, rpmfi and rpmds to
internal-only APIs for now. The kind interfaces we'll want to eventually
export a) dont exist yet and b) are likely to be something very different.
- The string pool itself remains exported however, its a handy data
structure for all sorts of things and both librpm and librpmbuild
heavily use it already.
- 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.
- There are no guarantees Fread() will return all of the requested size:
it can return partial data eg on signals and pipe descriptors. Introduce
a helper function to handle this centrally for all package read IO,
effectively reintroducing timedRead() but without the caveats:
timedRead() did not work on compressed streams, did not handle
eg EINTR correctly and while really being an internal helper,
was exported in the API.
- When the "BEGIN PGP" marker is not found at all, we would silently
exit with success when trying to import utter garbage, such as
rpmkeys --import /bin/bash (not that I consider bash as gargabe ;)
- Prior to string pool existence, the static "caches" were kinda
necessary for sharing the relatively static content of user/group
names and file languages, but this is nothing but an unfreeable
block of memory at this point. Just use the same pool as everything
else - whether private or shared.
- 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
- If link or regular file sizes differ, they cannot possibly be
identical. Saves us from doing bunch of pointless string and
memory comparisons on what's a very busy path - not exactly a huge
with but measurable nevertheless.
- The filter wasn't doing what it was supposed to due to extra single
quotes getting inserted, causing "rpmbuild --target noarch foo.spec"
to whine about empty macro bodies. This is a regression introduced
in rpm 4.10, commit 07ec480c18 to be
precise.
Add compatibility support for both lua-5.1 and lua-5.2,
assuming that the LUA_COMPAT might have been disabled.
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
- Calculating digest of %ghost config is useless as there's nothing
to compare the result to. Also we never take backups of %ghost
configuration anyway, so this is a total waste of time. One common
case of %ghost %config is the rpmdb (environment and all) which
can be rather large and calculating digests can take several seconds,
only for the results to be thrown away unused.
- There are some cases where it might be reasonable to back up %ghost
%config (eg if it gets replaced by non-config), but
rpmfiConfigConflictIndex() doesn't have sufficient context to figure
that out. For now, preserve the traditional simple rule: no backups
for ghosts, ever.
- Related to commit bee348b5d1,
use the newly added obsoletes hash to lookup already added
obsoleters. Eliminates the dumb linear lookup and is unsurprisingly
a whole lot faster on larger transactions.
- Similar lazily created hash as provides for fast obsoletes lookups.
This is so similar the provides that creation etc functions should
be unified, but leaving that exercise till later.
- Use indexed access to the dependencies so we're not mucking with
the rpmds iterator index behind anybodys back, this could affect
all sorts of things but miraculously nothing is hitting it atm...
- Add an internal header for rpmds too to allow adding interfaces we
dont necessarily want to export in the public API, make the indexed
accessors available internally.
- Various places in rpm need random access to the dependency sets,
save and restore on somebody elses "iterator index" just doesn't
cut it. This is merely preliminaries for further changes.
- Separate provides and files hash creation, delay both until the last
moment before first valid lookup. In practise, this means the provides
hash is created early due to lookups from rpmtsAddInstallElement(),
but the big bad file hash creation is delayed until the entire
transaction set has been more-or-less populated. Which means we have
a better idea about the necessary hash table size, meaning fewer
hash resizes, resulting in good deal faster execution with no
downsides - if something happened to trigger an early file lookup
it'll all still work, just slower.
- Replace the dumb linear search across all elements on each
addition with (filtered) rpmal lookups where possible. rpmal
doesn't (yet) have obsoletes information so for already added
obsoletions we have no choice but to walk the walk.
- As a result, findPos() is hugely faster for large transactions
but rpmal hashes are now generated on the fly for everything
instead of doing it all at once before the actual dependency
checks / ordering, which will cost us something in terms of
hash table resizes.
- rpmRelocateFileList() doesn't modify anything when no relocations
are to be done, but what it does is not exactly free, unnecessarily
calling it is dumb.
- The provides hash lookup can and does return hits that dont actually
satisfy the dependency. Dont bother callers with apparent hits
(ie non-NULL returns) when nothing actually matches the dependency.
- Avoids a little bit of extra work, we already have the relevant
bits of information in the rpmte and grabbing them from there is
cheaper than looking up stuff from headers. Also avoids creating
another copy of the new elements obsoletes dependency set unnecessarily.
- Now that the relevant places are accepting file index as argument,
we no longer need to save and restore fsm->ix in all the places
dealing with hard links.
- Normally this is just the current index, but when writing links
its something else and makes sense as an argument (so we dont
need to save and restore fsm->ix when doing something different)
- Normally this is just the current index, but when writing links
its something else and makes sense as an argument (so we dont
need to save and restore fsm->ix when doing something different)
- Normally this is just the current index, but when writing links
its something else and makes sense as an argument (so we dont
need to save and restore fsm->ix when doing something different)
- Return the hard link set from saveHardLink() when ready into a local
variable in the only place that cares: rpmPackageFilesInstall().
Another pointless and hard-to-follow fsm-global state variable
gone...
- saveHardLinks() is the only place where fsm->li value matters on
return: during installation its used for "returning" the current
link set when all the links in that set have been seen so they
are ready for creating.
- fsmMakeLinks() operates on the current link at hand, doesn't walk
the links or anything... pass the link as an argument from the sole
caller and operate on that.
- Using a "global" variable for local... more of the same:
fsmCommitLinks() gets called at the end of each round of the install
loop if there are links, it does the actual link discovery on its
own and fsm->li state will get rewritten by saveHardLink() at the
start of the next round.
- Legitimately skipped files (links) must not cause install-errors.
This has always been broken, but the errors were completely ignored
on install prior to rpm 4.10, and now that we're only creating the
first instance of a shared file, secondary arch multilib packages
with hardlinks were causing install failures because of the "missing"
hardlinks here.
- The relevant part here is obviously the XFA_SKIPPING() test, for
which we need the file states. To keep the lines short, grab the
index to a helper variable and replace other fsm->li->filex[i] uses
with that too.
Panu Matilainen