The code in rpmdb already supports fingerprinting, which led to
file dependency problems being reported against installed packages,
but ignored for against new packages.
The use of the fingerprinting code does not seem to make the
dependency check slower in my tests.
- Look at all providers and calculate a simple score for them:
We want to prefer self-provides during ordering (RhBug:1111349)
but only when other things are equal, coloring needs to prevail.
Otherwise ordering can miss crucial dependencies to the preferred
arch packages whose files are actually laid down: eg on x86_64
Fedora, both glibc.i686 and glibc.x86_64 provide and require
/sbin/ldconfig, but only installing glibc.x86_64 will actually
get the file on disk for itself and others to use, so glibc.i686
cannot satisfy its own /sbin/ldconfig provide, crazy as it is.
- Also fixes a memleak on self-provided dependencies introduced
in commit 6b6f8e6ecb
- 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
- These all operate on rpmfiles, not rpmfi, now so make the point
clearer. All internal stuff so we're free to mess around.
- No functional changes, only a straightforward perl-assisted rename...
- The self-iterator in rpmfi prevents all sorts of sane uses of
file set iteration. Split the actual data into a separate data
type, changing the internal random-access functions to use the
new rpmfiles datatype directly and update internal callers minimally.
This should be entirely transparent to public API consumers who still
only see the braindamaged self-iterating version.
- Internal consumers dont directly benefit (yet), this is just an
early step on the road to rpmfi sanity. Much of the API and variables
will need renaming etc but avoiding that here to keep the changes
to minimum, this is a rather huge commit as it is.
- 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...
- 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.
- 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.
- We need to grab the dependency string in rpmalAllSatisfiesDepend()
already to see whether its a file dependency or not, just pass that
to the file deps to avoid redundant work.
- 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.
- Files which dont get installed cannot very well satisfy dependencies,
take this into account for docs and configs when --nodocs & --noconfigs
flags are used.
- There are places in rpmio and build that would benefit from hashing, but
hashFunctionString() being internal to librpm has prevented that. Rename
to rstrhash() to resemble the other foo in rpmstring.h for
minimal namespacing as its now public function and update callers.
- Also mark the function as "pure" - it only looks at its arguments.
This is one of the busiest functions in entire rpm so any optimization
no matter how minor is well worth it.
- Hereby awarding hashFunctionString() with the grand prize for
the Most Moved Around Function in rpm ;)
This patch adds the install-time feature that if a package requires a package
in a collection, then it also requires all other packages in that collection.
This has the effect that collections will be roughly grouped together during a
transaction.
Although this is not absolutely necessary for the majority of collections, it
is required for the SELinux collection. This is because all SELinux policies
must be installed before the applications they secure to ensure correct labels.
This means we must ensure packages in the selinux collection are ordered
earlier in the transaction than all applications they protect. Adding this
implicit runtime requirements achieves this in a general manner, without major
modifications to dependency ordering.
To accomplish this, this patch splits the addRelation function into two parts:
one that determines which relations to add, and one that actually adds them.
After the usual relation is added between two packages, it then determines if
the required package contains any collections. If so, it finds all other
packages that are in the same collections and creates additional relations.
- Besides there not being much point in having a separate source + header
for a small single function, this fixes build on case-insensitive
systems such as Mac OS X.
- the "new" hash-based rpmal only uses rpmalMakeIndex() for initial
creation of the hash tables as late as possible for better estimate
of needed hash size, but doesn't require any index regeneration if something
is added
- first call to rpmalSatisfiedDepend() now initializes the hashes, if
significant amount of entries are added after the first call hash
table might get full ... so dont do that ;) (this was already true
with rpmalMakeIndex(), now its just hidden out of sight)
- Instead of blindly picking the first match, try to pick the best provider
for the dependency: for colored dependencies, try to find a provider of
matching color. For non-colored dependencies, prefer providers of
transaction preferred color.
- This avoids creating bogus and loopy relations between 32- and 64-bit packages
where they dont exist, and makes behavior with things like /sbin/ldconfig
consistent by returning the preferred colored element.
Michael Schroeder