summaryrefslogtreecommitdiff
path: root/lib/rpmts_internal.h
Commit message (Collapse)AuthorAgeFilesLines
* Refactor db iterator locked to single rpmte to a common helper functionPanu Matilainen2022-10-201-0/+4
| | | | | Two places doing the same thing, they also share all the bugs... No functional changes here.
* Remember used keyring type in the transaction setPanu Matilainen2022-03-311-0/+1
| | | | | | The keyring a transaction uses shouldn't change by somebody defining macro in the meanwhile. Add an enum for known types and a helper to lazily determine it on the first keyring load.
* Allow an optional "override clock" for deterministic timestampsBenno Rice2021-11-231-0/+5
| | | | | | | | | | | | | | | | | | | When trying to achieve a fully reproducible build process for an OS image timestamps are a major source of variance. The RPM database contains two fields in package header records that are relevant here: - RPMTAG_INSTALLTIME which is an explicit timestamp indicating when the package was installed. - RPMTAG_INSTALLTID which is an opaque value represending the transaction ID under which a package was installed but in terms of internal implementation is also a timestamp. This change allows the presence of the SOURCE_DATE_EPOCH environment variable, commonly used to override timestamps in build systems, to institute an "override time" mode in which values for RPMTAG_INSTALLTID and RPMTAG_INSTALLTIME become predicatble.
* Implement alternative transaction callback style with transaction elementsPanu Matilainen2020-10-051-0/+1
| | | | | | | | | | | Add API to get and set callback style, defaulting to the good ole header first style and add a new style where a transaction element is passed in place of the header, allowing a much saner interaction. This is doubly so in Python, where the old style callback is a braindamaged mess. In the new mode the "key" is not passed as separate argument at all, it can be just as well retrieved via te.Key() for the callbacks needing it.
* Implement a transaction set change notification callbackPanu Matilainen2020-09-301-0/+7
| | | | | | | | | | | | | | Add support for an optional callback hook for reveiving notifications about added and deleted transaction elements. This lets API clients easily track which elements get created and/or replaced by a single rpmtsAddFoo() call and adjust their own book-keeping accordingly. Also makes for an easy place to set application private data pointers for newly added elements. Currently there's no way to delete individual transaction elements from the API but that can happen via rpmtsEmpty(), which we do send notifications for. rpmtsFree() does NOT send notification though, it would be precarious and most likely totally pointless to do so when the ts is being torn down.
* Add a public API for controlling package verification flagsPanu Matilainen2018-06-271-0/+1
| | | | | | | | | | | | | | We can't use the existing transaction vsflags for package verification purposes due to legacy misuses and fundamental differences - vsflags defaults are very different and change can't really be relied on as this is all tangled up in legacy issues, misuses and misunderstandings in 3rd party code and whatnot. I dont see a way to unify them in foreseeable future, unfortunately. So add another API... Rename _vsflags_pkgverify to _pkgverify_flags to differentiate it from the other vsflags (because it is different), add get/set API for it in transaction sets and use where immediately obvious (but there's the rpm cli install case left to deal with)
* Rename vslevel back to vfylevel everywhere, sighPanu Matilainen2018-06-271-1/+1
| | | | | | | | | | rpmtsVSFlags() doesn't actually control what happens with the package verification that vslevel/vfylevel relates to, it controls the verification that happens on header/package read. We actually need a separate API for controlling the flags that control the operation that verify level is associated with, so to avoid total confusion as to what is what... paving way for adding rpmtsVfyFlags(), but that's not added in this commit - rename only.
* Move verify level configuration to transaction set public APIPanu Matilainen2018-06-201-1/+1
| | | | | | | | This makes it all more in line with how rpm does things overall, and also we might want different policies for eg chroot installs and system installs etc. Also makes it exporting the API easy. Rename vfylevel -> vslevel to make the close relation clearer. No behavior changes though.
* Always execute scriptlet callbacks with owning header (RhBug:1485389)Panu Matilainen2017-09-041-1/+1
| | | | | | | | | | | | | | | Triggers and file triggers can and do execute scriptlets from installed packages which are not part of the current transaction and thus have no associated transaction element, making the scriptlet callbacks inconsistent and cumbersome for API users. Create a fake transaction element for the poor orphan scriptlets lacking one to make it consistent (of course, creating rpmte's with all their associated data just to pass a header pointer along is ridiculously expensive but *shrug*). Regular triggers used to execute in the context of the triggering transaction element, make them run with the owning trigger header too.
* Add mode for updating with minimal writing (RhBug:783480)Pavlina Moravcova Varekova2017-04-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | How does the number of writes change? I compared number of writes with and without minimal writing for upgrade from RHEL 7.0 to RHEL 7.1, from RHEL 7.1 to RHEL 7.2, ... In more details, the size of memory used for writing regular files. The following table contains in the second column percentages of files which can be only touched from all installed files. In the third column, there are percentages of sum of their sizes. | Touched | Touched | Updated files | Updated bytes ------------------------------------------------------------------------ RHEL 7.0 -> RHEL 7.1 | 63 % | 66 % RHEL 7.1 -> RHEL 7.2 | 53 % | 43 % RHEL 7.2 -> RHEL 7.3 | 60 % | 42 % ------------------------------------------------------------------------ F24 -> F25 | 63 % | 40 % F25-> Fraw | 49 % | 28 % Does the speed change? The update speed for classical disks or SSD almost does not change. How it works? If there is a file in the new package, which has the equal digest as the corresponding file in the old package and the same file on the disk (thus the contents are expected to be equal), rpm will not install the whole file, but rather only upgrade the file's meta data. In other cases, it will install the whole file.
* File triggers moved to own fileLubos Kardos2015-07-231-14/+2
|
* Add support for %transfiletriggerun.Lubos Kardos2015-02-051-0/+19
|
* Add support for executing file triggers.Lubos Kardos2015-02-051-0/+13
| | | | | | | | | Supported file triggers: %filetriggerin %filetriggerun %filetriggerpostun %transfiletriggerin %transfiletriggerun
* Add hash installedPackages to transaction members structure.Lubos Kardos2015-02-051-1/+2
| | | | | | | | - After transaction this hash contains all packages installed in transaction. This hash can be used as argument of rpmdbFilterIterator() to get all packages installed in transaction from rpmdb. - Rename removedHash to packageHash.
* Make rpmtsPrunedIterator() internally availablePanu Matilainen2014-03-041-0/+5
|
* Initialize plugins much earlierPanu Matilainen2013-04-031-0/+2
| | | | | | | | | | | | | | | | | - Lazily initialize plugins when adding install or erase elements to the transaction already. Since this ensures the setup will always be performed, there's no need to do this from rpmtsRun() anymore, empty transaction would not get that far anyway. - This will allow adding hooks to the places where package header is still available (which is required for various things) and in general, before transaction is actually executed. - The downside here is that adding or removing packages to a transaction can now fail due to plugin initialization failure where its not easily distinguishable from other errors, but then they can also fail due to rpmdb open failure which kinda similar "shouldn't be here" issue. The alternative would be initializing the plugins in rpmtsCreate() but as that's not actually permitted to fail at all, its not an option really.
* Eliminate leftover selabel handle from rpmts structPanu Matilainen2013-04-031-2/+0
| | | | | - This should've gone down with the dishwater in commit b5e3e1efee28ce0a4bb5e9eae6740d4422f75f1c
* Eliminate built-in selinux support. RIP.Panu Matilainen2013-03-211-22/+0
| | | | | | | | | | | | | | - We hereby unceremoniously declare that from now on, SELinux and other similar mechanisms are to live in plugins, rpm doesn't need to know about every possible security etc mechanism there might be. Its a big commit but as its really just removals... - We need to disable sepolicy collection plugin for now as it relies on built-in support for selinux, this not only makes no sense but wont work now that there is no built-in support. The sepolicy plugin needs to be merged into the selinux base plugin now. - Another "breakage" is that --rebuilddb no longer relabels the database, this needs plugins to called in a place where they currently cannot be called. This needs to be resolved before next actual release.
* Export rpmtxnBegin() and rpmtxnEnd()Panu Matilainen2013-03-111-15/+0
| | | | | | | | | | | - This allows API users to lock the transaction from other players long before entering rpmtsRun(): for example depsolvers first do calculations based on the rpmdb, download packages and only then start the transaction. We dutifully waited for others to complete on the ts lock inside rpmtsRun(), but those others could've invalidated all our prior calculations so continuing was potentially hazardous even. There are other uses too, we'll get to them eventually...
* Move transaction lock handle to transaction set centrallyPanu Matilainen2013-03-111-0/+1
| | | | | | | | - Separate lock object creation from lock acquisition: lazily (try to) create the lock object from rpmtxnBegin() if it doesn't already exist, otherwise rpmtxnBegin() and rpmtxnEnd() just acquire and release the lock. After all this trouble, we can actually nest transaction locks. At least in theory ;)
* Introduce transaction begin/end API on top of rpmlockPanu Matilainen2013-03-111-3/+15
| | | | | | - For now this doesn't do anything particularly interesting, it just replaces the transaction lock handle we use internally. We want to export this interface but that needs further changes.
* Handle transaction global pool allocation centrally in rpmtsPool()Panu Matilainen2012-12-191-1/+1
| | | | | | | | | | | | | - Previously the pool would only get allocated on successfull addition of install or erasure elements, causing assert() failures on operations on empty transaction set, which should be just a no-op, not an error. - Make rpmtsPool() create the pool if it doesn't exist, update relevant users to call rpmtsPool() instead of directly accessing tsmem->pool, this avoids having to worry about pool existence in all the various cases. - Also fix up the pool-related comment on rpmtsEmpty(): pools does not and can not support emptying as it could break references to its contents. Per-string refcount would be needed for emptying support.
* Hide the strpool-related rpmts/rpmfi/rpmds interfaces out of sight for nowPanu Matilainen2012-11-011-0/+8
| | | | | | | | | | | - 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.
* Bury the fingerprint hash-types into fprint.c, clean upPanu Matilainen2012-09-141-0/+1
| | | | | | | - fprint.h only needs rpmtypes.h now, remove historical leftovers - Avoids having to define the hash types multiple times as they're now buried out of sight - fpHashFunction() and fpLookupSubdir() can now be made static, do so...
* Hang rpmlib() dependency set onto transaction setPanu Matilainen2012-09-131-0/+1
| | | | | | - Eliminates the cumbersome static rpmlib ds instance which can never be freed, as a member of the transaction set it simply gets cleaned out along with other transaction (dependency) data.
* Add infastructure for global transaction set string poolPanu Matilainen2012-09-121-0/+2
| | | | | | | | | | | | - Add a pool pointer to to ts members struct and a getter function - Grab the global pool for rpmte dependency- and file info creation, if its NULL then the sets will use private pools of their own. - Add the (currently) required magic voodoo rain-dance to freeze and unfreeze the pool as necessary wrt new element additions: for current rpmal and fingerprinting to work, the string pointers must be immovable. - This is infrastructure only: nothing creates the global pool yet, so everything is still using private pools.
* Add an nternal rpmal create+populate helper function, use for erased packagesPanu Matilainen2012-09-121-0/+3
| | | | - We'll need this shortly for added packages too...
* Store transaction element pointers in the removedPkgs hashPanu Matilainen2012-08-301-1/+1
| | | | | | | | | - 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.
* remove the 'path' parameter of rpmtsSELabelInit()Ales Kozumplik2012-01-121-2/+1
| | | | - It is always selinux_file_context_path() anyway.
* selinux: reopen label between transactions if necessary (RhBug: 746073)Ales Kozumplik2012-01-121-3/+5
|
* Move rpmtsSELabelFoo() functions to an internal-only headerPanu Matilainen2010-12-211-0/+21
| | | | | | | | - The sepolicy plugin needs them so the symbols can't be hidden, but these are not something external API-users should be messing with. - Ultimately we'll want to push the actual labeling from FSM to the plugin, insulating rpm from all SELinux specifics, this is just a band-aid temporary "solution" to keep this out of the API.
* Add "c++ protection" to (hopefully) all of our internal headersPanu Matilainen2010-09-211-0/+8
|
* ...and finally eliminate the spec crapola from transaction set for goodPanu Matilainen2010-09-011-2/+0
|
* Use selabel interfaces instead of matchpathconSteve Lawrence2010-09-011-0/+2
| | | | | | | | | | | | | | | | | | | | | This replaces the old matchpathcon interfaces with the new selabel interfaces for relabeling files, storing an selabel handle in the transaction set. With this change, also comes an added distinction between --nocontexts being specified and a failure to read the load file contexts. Previously, there was no distinction, and both cases used the RPMTRANS_FLAG_NOCONTEXTS flag. However, with the new policy plugin, it is necessary to make such a distinction. This is because matchpathcon_init (now selabel interfaces) can fail at the beginning of the transaction, but succeed later after new policy is installed. Because of this, we may need to enable/disable RPMTRANS_FLAG_NOCONTEXTS multiple times. However, because this flag could also mean --nocontexts, we cannot do that. By storing the selabel handle in the rpmts, we can easily keep track if the handle has been successfully created, rather than overloading RPMTRANS_FLAG_NOCONTEXTS with two meanings.
* Update the plugin architecture to allow for remembering stateSteve Lawrence2010-09-011-0/+2
| | | | | | | | | | | This moves most of the plugin logic to a new rpmplugins file with a struct and functions for managing plugins, allowing for plugins to carry state. This also adds init and cleanup hooks for plugins to initialize and cleanup their state, and a new 'open te' hook allowing plugins to read and save information from transaction elements. This also generalizes the plugin architecture a bit so it isn't so specific to collections.
* Lose the now unnecessary rpmtsSELinuxEnabled() functionPanu Matilainen2010-08-131-1/+0
| | | | | | | - it never was anything more than a cached value of is_selinux_enabled() and caching this fairly expensive result is no longer needed as scriptlet execution wrt selinux contexts is now conditionalized on RPMTRANS_FLAG_NOCONTEXTS instead
* numAddedPackages is unused since rpm 4.8.0, eliminatePanu Matilainen2010-06-221-2/+0
|
* Use the new chroot API everywhere, eliminate old related gooPanu Matilainen2010-05-311-2/+0
|
* Move the lone hashFunctionString() into misc.[ch], eliminate rpmhash.[ch]Panu Matilainen2010-05-211-1/+0
| | | | | | - 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.
* Convert tsmem->removedPackages to a hash table and remove rpmdbPruneIterator ↵Florian Festi2010-05-061-3/+1
| | | | from the API
* Make transaction lock path per-transactionPanu Matilainen2010-04-221-0/+1
| | | | | | | | - Although it doesn't really happen in practise, rpm's API permits several transactions with possibly differing roots within process lifetime. Previously the lock path was calculated just once globally so we could easily be locking in a completely wrong place (eg locking in a previously accessed chroot when system rpmdb should be transaction-locked)
* Further generalize the rpmlock interfacePanu Matilainen2010-04-221-0/+3
| | | | | | | - Move transaction lock path handling into rpmts.c, export new low level rpmlockAcquire() function to actually grab a lock - Rename rpmtsFreeLock() to rpmlockFree() and return NULL in the general rpm style
* Default to "not found" for rpmtsSolve() + comment behaviorPanu Matilainen2010-03-141-0/+1
| | | | | - this fixes the behavior when (as normally is the case) there is no depsolve callback set
* Add internal API for depsolve callbackPanu Matilainen2010-03-121-0/+3
| | | | - rpmts struct is now fully opaque within depends.c
* Record problems into the transaction elements causing themPanu Matilainen2010-03-121-1/+0
| | | | | | | | | | | | | | | | | - Any problem found in transaction processing is caused, or at least triggered by, some transaction element. Having the problems in elements lets API users easily determine which package caused which problem instead of having to parse problem strings in vain. - No problem set stored in transaction set itself now, rpmtsProblems() API p reserved by making it collect problems from our transaction elements into a new set. The problem set fiddling in rpmtsRun() wrt %pretrans and all is a bit crazy - always was, now its just more visible... - Make rpmtsCheck() pass the associated transaction elements into the lower level functions. rpmdsProblem() removed from API, it's not particularly useful outside rpmtsCheck() internals. - rpmts struct is now opaque within depends.c except for solve callback - This breaks --badreloc, need to figure out something saner for the problem filtering
* Split transaction member information out of rpmts to separate structPanu Matilainen2010-03-121-11/+19
| | | | | | | - add internal rpmtsMembers() function to get the member structures - the main rpmts struct is now opaque within order.c, and much closer to being so for depends.c and transaction.c too - no functional changes
* Remove no longer neede rpmts->filesystemCount and->filesystemsFlorian Festi2010-02-051-2/+0
|
* Remove unused ordering related members from rpmts structPanu Matilainen2009-12-211-2/+0
|
* Eliminate transaction disk space checking functions from the APIPanu Matilainen2009-12-151-26/+1
| | | | | | - The DSI stuff runs from deep inside rpmtsRun() with no chance for API users to do anything with it. Bury into transaction.c and make static to let us change the way it works without API constraints...
* Make disk space problem reporting slightly saner (RhBug:517418)Panu Matilainen2009-10-271-0/+2
| | | | | | | | - Only report disk space/inode issues for packages that are affected instead of piling up all the problems in all filesystems on all remaining packages - The messages are still ambiguous at best, need to figure out something better one of these days...
View Lorry Controller Status