summaryrefslogtreecommitdiff
path: root/apt-pkg/pkgcache.h
Commit message (Collapse)AuthorAgeFilesLines
* Add missing #include <string_view>Julian Andres Klode2025-02-151-0/+1
|
* cache: Introduce partial SourceVersion supportJulian Andres Klode2025-02-151-8/+37
| | | | | | | | | | | | This is the first step that introduces a 1:1 mapping between version and source version. In a future version this can use the fields currently marked unavailable to deduplicate the SourceVersion objects across the group. The policy gains a member for storing pins for sourceversions. Together, in the future we should be able to determine candidates for source versions.
* Run unifdef -DAPT_PKG_ABI=700 againJulian Andres Klode2025-02-151-11/+0
| | | | | main picked up a couple new ifdefs since the branch started; so clean them up again.
* APT::StringView -> std::string_view [textonly]наб2025-02-141-9/+8
|
* Drop unused version stanza size info from binary cacheDavid Kalnischkies2025-01-301-2/+3
| | | | | | | | | | | | | | Same reason as with the description size before, but this one had actually one extremely dated user in src:apt left with dumpavail, which is changed to an implementation that is (in comparison) a bit slower, but should be good enough for a command that is ideally not used anymore (even if codesearch suggests otherwise). After all, what makes this a bit slower is not that we don't know the size, but that this one does additional work preparing for accessing the fields which we don't do. In exchange pkgTagFile has a better implementation for "Jitter" than the old code that we would "just" need to copy here if speed were really an issue.
* Drop unused description size info from binary cacheDavid Kalnischkies2025-01-301-2/+3
| | | | | | | | | | | Nothing in src:apt uses this information and that isn't all to surprising as it is usually not that interesting to know how big a specific stanza of a description is as the max size is available and you are usually working with more than one description. So this information just takes up space in our binary cache… 64 bits per structure which can quickly add up to whole MBs depending on how many (and which) sources you have enabled.
* Do not overflow ver/desc<->file relation countersDavid Kalnischkies2025-01-301-0/+5
| | | | | | | | | | | | | | | | The counters aren't used for anything really except for the 'stats' command that is off in its display and calculation due to 16bit not being enough for counting all the relations we have. Semi-broken more than a decade ago as I accidentally aligned it with the other file relation counters which count far less frequent ones through, so 'unsigned long' should have been changed to the id type rather than the smaller fileid type. Of course, this commit only prepares the fix as this would be an ABI break, so with the current ABI we are still overflowing. Regression-of: 4ad8619bb1f0bf777d17c568bb7a6cf7f30aac34
* Add pkgCache::{Priority,DepType}_NoL10n to avoid duplicationDavid Kalnischkies2025-01-051-1/+3
| | | | | | We don't have many places, but lets reduce the amount of duplicating these short strings, so that we may find all the places we have to change if that ever happens.
* Modernize standard library includesJulian Andres Klode2024-02-201-3/+3
| | | | | | This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces.
* Invalidate cached architecture list when building cacheJulian Andres Klode2021-10-191-1/+1
| | | | | | | | Fix a regression in python-apt where switching the architectures in the config between cache invocations regressed. Regression-Of: 8ff4e226af55a9feb168477a2b1a99f9c5152e54 Gbp-Dch: full
* All pkgCaches are MultiArch cachesDavid Kalnischkies2021-09-041-1/+1
| | | | | | | | | | | | | | | Back in 2015 the code inside libapt who was using this field was dropped as even if we are on a system which is not configured for MultiArch, there are still edge cases in which the cache can include very foreign packages, so any assumption you could make thinking only a single architecture will be in the cache is probably wrong. Maintaining two different codepaths for Multi- and SingleArch is likely not very beneficial for code and users alike and is surprisingly hard to answer correctly and becoming even harder still, so always assuming the "worst case" seems like the far better option. References: 6c9937da76b9155d166092b9dda22d06200510c1
* Add support for Phased-Update-PercentageJulian Andres Klode2021-01-081-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for Phased-Update-Percentage by pinning upgrades that are not to be installed down to 1. The output of policy has been changed to add the level of phasing, and documentation has been improved to document how phased updates work. The patch detects if it is running in a chroot, and if so, always includes phased updates, restoring classic apt behavior to avoid behavioral changes on buildd chroots. Various options are added to control this all: * APT::Get::{Always,Never}-Include-Phased-Updates and their legacy update-manager equivalents to always or never include phased updates * APT::Machine-ID can be set to a UUID string to have all machines in a fleet phase the same * Dir::Etc::Machine-ID is weird in that it's default is sort of like ../machine-id, but not really, as ../machine-id would look up $PWD/../machine-id and not relative to Dir::Etc; but it allows you to override the path to machine-id (as opposed to the value) * Dir::Bin::ischroot is the path to the ischroot(1) binary which is used to detect whether we are running in a chroot.
* Add correct std namespace to nullptr_tDavid Kalnischkies2020-04-261-3/+3
| | | | | Reported-By: clangd Gbp-Dch: Ignore
* pkgcache: Add operator bool() to map_pointerJulian Andres Klode2020-02-271-0/+1
|
* apt-pkg: default visibility to hiddenJulian Andres Klode2020-02-261-1/+1
|
* cache: Swap locations of hashtables, hide them from non-apt usersJulian Andres Klode2020-02-261-2/+5
| | | | | Only expose the locations of the hasthables if APT_COMPILING_APT is set.
* Add d-pointers to groups, packages, versions, and filesJulian Andres Klode2020-02-251-2/+17
| | | | | | | | This allows us to extend those in-cache objects with more data later on without breaking the ABI. Reserve 12 pointers for private data in the pkgCache class, and double the size of pools to 24.
* Make map_pointer<T> typesafeJulian Andres Klode2020-02-241-1/+21
| | | | | | | | | | | Instead of just using uint32_t, which would allow you to assign e.g. a map_pointer<Version> to a map_pointer<Package>, use our own smarter struct that has strict type checking. We allow creating a map_pointer from a nullptr, and we allow comparing map_pointer to nullptr, which also deals with comparisons against 0 which are often used, as 0 will be implictly converted to nullptr.
* Replace map_pointer_t with map_pointer<T>Julian Andres Klode2020-02-241-48/+48
| | | | | | This is a first step to a type safe cache, adding typing information everywhere. Next, we'll replace map_pointer<T> implementation with a type safe one.
* Use a 32-bit djb VersionHash instead of CRC-16Julian Andres Klode2020-02-181-1/+1
|
* Merge branch 'pu/source-version' into 'master'Julian Andres Klode2020-02-181-1/+11
|\ | | | | | | | | ABI BREAK: Implement pinning by source package See merge request apt-team/apt!96
| * Allow querying all binaries built by a source packageJulian Andres Klode2020-01-171-1/+11
| | | | | | | | | | | | This adds a simple way to lookup binaries by a source package, but this adds all binaries into one list, even with different source versions. Be careful.
* | Revert "Add a Packages-Require-Authorization Release file field"Julian Andres Klode2020-02-161-5/+3
|/ | | | | | | | This experiment did not turn out sensibly, as some servers do not accept credentials when none are expected and fail, so you cannot mirror such a repository. This reverts commit c2b9b0489538fed4770515bd8853a960b13a2618.
* Run unifdef -DAPT_{8,9,10,15}_CLEANER_HEADERSJulian Andres Klode2019-06-121-3/+0
|
* Make APT::StringView publicJulian Andres Klode2019-06-111-24/+5
|
* pkgcache: Remove deprecated bitsJulian Andres Klode2019-02-261-20/+0
|
* Add a Packages-Require-Authorization Release file fieldJulian Andres Klode2019-02-011-3/+5
| | | | | | | | | | | | | | | | | This new field allows a repository to declare that access to packages requires authorization. The current implementation will set the pin to -32768 if no authorization has been provided in the auth.conf(.d) files. This implementation is suboptimal in two aspects: (1) A repository should behave more like NotSource repositories (2) We only have the host name for the repository, we cannot use paths yet. - We can fix those after an ABI break. The code also adds a check to acquire-item.cc to not use the specified repository as a download source, mimicking NotSource.
* Replace APT_CONST with APT_PURE everywhereJulian Andres Klode2017-08-241-2/+2
| | | | | As a follow up to the last commit, let's replace APT_CONST with APT_PURE everywhere to clean stuff up.
* cacheiterators: Warn about direct include and don't include pkgcache.hJulian Andres Klode2017-07-121-1/+2
| | | | | | This adds a warning so existing working code will still work (as it includes pkgcache.h first anyway), but it will know that it's not right to include this file directly.
* Reformat and sort all includes with clang-formatJulian Andres Klode2017-07-121-6/+9
| | | | | | | | | | | | | This makes it easier to see which headers includes what. The changes were done by running git grep -l '#\s*include' \ | grep -E '.(cc|h)$' \ | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/' To modify all include lines by adding a space, and then running ./git-clang-format.sh.
* Store the size of strings in the cacheJulian Andres Klode2016-01-081-0/+10
| | | | | By storing the size of the string in the cache, we can make use of it when comparing the names in the hashtable in pkgCache::FindGrp.
* Switch performance critical code to use APT::StringViewJulian Andres Klode2016-01-071-1/+16
| | | | | | This improves performance of the cache generation on my ARM platform (4x Cortex A15) by about 10% to 20% from 2.35-2.50 to 2.1 seconds.
* Add support for calculating hashes over the entire cacheJulian Andres Klode2015-12-291-1/+3
|
* add messages to our deprecation warnings in libaptDavid Kalnischkies2015-11-271-4/+4
| | | | Git-Dch: Ignore
* do not report deprecate warnings for the None declarationDavid Kalnischkies2015-09-141-0/+2
| | | | | | | | This is defined for compatibility, warning about it is intended, but only in places where it is actually used, rather than at the place we declare it for compatability… Git-Dch: Ignore
* remove incorrect optimization branchesDavid Kalnischkies2015-09-141-1/+0
| | | | | | | | | | | | These assumptions were once true, but they aren't anymore, so what is supposed to be a speed up is effectively a slowdown [not that it would be noticible]. Usage of SingleArchFindPkg was nuked in a stable update already as the included assumption was actually harmful btw, which is why we should get right of other 'non-harmful' but still untrue assumptions while we can. Git-Dch: Ignore
* Make pkgCache::Priority() static, it does not need the instanceJulian Andres Klode2015-08-161-1/+1
| | | | | | It still compiles after the change, so just merge it. Closes: #448627
* Drop the Section field from pkgCache::Package againJulian Andres Klode2015-08-121-6/+0
| | | | | | This somehow got back, we don't really know why. Emulate the Section() method in the PkgIterator by looking at the section of the head of the VersionList.
* Re-introduce None as a deprecated alias for NoJulian Andres Klode2015-08-111-0/+4
| | | | Gbp-Dch: ignore
* no value for MultiArch field is 'no', not 'none'David Kalnischkies2015-08-101-1/+1
| | | | Git-Dch: Ignore
* hide implicit deps in apt-cache again by defaultDavid Kalnischkies2015-08-101-4/+12
| | | | | | | | | | | | | | Before MultiArch implicits weren't a thing, so they were hidden by default by definition. Adding them for MultiArch solved many problems, but having no reliable way of detecting which dependency (and provides) is implicit or not causes problems everytime we want to output dependencies without confusing our observers with unneeded implementation details. The really notworthy point here is actually that we keep now a better record of how a dependency came to be so that we can later reason about it more easily, but that is hidden so deep down in the library internals that change is more the problems it solves than the change itself.
* use a smaller type for flags storage in the cacheDavid Kalnischkies2015-08-101-27/+30
| | | | | | | | We store very few flags in the cache, so keeping storage space for 8 is enough for all of them and still leaves a few unused bits remaining for future extensions without wasting bytes for nothing. Git-Dch: Ignore
* remove the compatibility markers for 4.13 abiDavid Kalnischkies2015-08-101-59/+15
| | | | | | | | We aren't and we will not be really compatible again with the previous stable abi, so lets drop these markers (which never made it into a released version) for good as they have outlived their intend already. Git-Dch: Ignore
* link DependencyData structs togetherDavid Kalnischkies2015-08-101-1/+3
| | | | | | | | | Cache generation needs a way of quickly iterating over the unique potion of the dependencies to be able to share them. By linking them together we can reduce the speed penality (~ 80%) with only a small reduction in saved size (~ 20%). Git-Dch: Ignore
* split-up Dependency structDavid Kalnischkies2015-08-101-9/+18
| | | | | | | | | | | | | | | | | | | | | Having dependency data separated from the link between version/package and the dependency allows use to work on sharing the depdency data a bit as it turns out that many dependencies are in fact duplicates. How many are duplicates various heavily with the sources configured, but for a single Debian release the ballpark is 2 duplicates for each dependency already (e.g. libc6 counts 18410 dependencies, but only 45 unique). Add more releases and the duplicates count only rises to get ~6 for 3 releases. For each architecture a user has configured which given the shear number of dependencies amounts to MBs of duplication. We can cut down on this number, but pay a heavy price for it: In my many releases(3) + architectures(3) test we have a 10% (~ 0.5 sec) increase in cache creationtime, but also 10% less cachesize (~ 10 MB). Further work is needed to rip the whole benefits from this through, so this is just the start. Git-Dch: Ignore
* make all d-pointer * const pointersDavid Kalnischkies2015-08-101-1/+1
| | | | | | | | | | | | | | Doing this disables the implicit copy assignment operator (among others) which would cause hovac if used on the classes as it would just copy the pointer, not the data the d-pointer points to. For most of the classes we don't need a copy assignment operator anyway and in many classes it was broken before as many contain a pointer of some sort. Only for our Cacheset Container interfaces we define an explicit copy assignment operator which could later be implemented to copy the data from one d-pointer to the other if we need it. Git-Dch: Ignore
* add d-pointer, virtual destructors and de-inline de/constructorsDavid Kalnischkies2015-06-161-2/+3
| | | | | | | | To have a chance to keep the ABI for a while we need all three to team up. One of them missing and we might loose, so ensuring that they are available is a very tedious but needed task once in a while. Git-Dch: Ignore
* hide Translation-* in 'apt-cache policy' outputDavid Kalnischkies2015-06-151-0/+1
| | | | | | | | | | | | | Translation-* files are internally handled as PackageFiles which isn't super nice, but giving them their own struct is a bit overkill so let it be for the moment. They always appeared in the policy output because of this through and now that they are properly linked to a ReleaseFile they even display all the pinning information on them, but they don't contain any packages which could be pinned… No problem, but useless and potentially confusing output. Adding a 'NoPackages' flag which can be set on those files and be used in applications seems like a simple way to fix this display issue.
* store Release files data in the CacheDavid Kalnischkies2015-06-121-12/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | We used to read the Release file for each Packages file and store the data in the PackageFile struct even through potentially many Packages (and Translation-*) files could use the same data. The point of the exercise isn't the duplicated data through. Having the Release files as first-class citizens in the Cache allows us to properly track their state as well as allows us to use the information also for files which aren't in the cache, but where we know to which Release file they belong (Sources are an example for this). This modifies the pkgCache structs, especially the PackagesFile struct which depending on how libapt users access the data in these structs can mean huge breakage or no visible change. As a single data point: aptitude seems to be fine with this. Even if there is breakage it is trivial to fix in a backportable way while avoiding breakage for everyone would be a huge pain for us. Note that not all PackageFile structs have a corresponding ReleaseFile. In particular the dpkg/status file as well as *.deb files have not. As these have only a Archive property need, the Component property takes over this duty and the ReleaseFile remains zero. This is also the reason why it isn't needed nor particularily recommended to change from PackagesFile to ReleaseFile blindly. Sticking with the earlier is usually the better option.
* rework hashsum verification in the acquire systemDavid Kalnischkies2015-06-091-1/+6
| | | | | | | | | | | | | | | | | | | | | Having every item having its own code to verify the file(s) it handles is an errorprune process and easy to break, especially if items move through various stages (download, uncompress, patching, …). With a giant rework we centralize (most of) the verification to have a better enforcement rate and (hopefully) less chance for bugs, but it breaks the ABI bigtime in exchange – and as we break it anyway, it is broken even harder. It shouldn't effect most frontends as they don't deal with the acquire system at all or implement their own items, but some do and will need to be patched (might be an opportunity to use apt on-board material). The theory is simple: Items implement methods to decide if hashes need to be checked (in this stage) and to return the expected hashes for this item (in this stage). The verification itself is done in worker message passing which has the benefit that a hashsum error is now a proper error for the acquire system rather than a Done() which is later revised to a Failed().
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2026-07-18 18:26:42 +0000