summaryrefslogtreecommitdiff
path: root/cmdline/apt-cache.cc
Commit message (Collapse)AuthorAgeFilesLines
* pkgnames: Do not exclude virtual packages with --all-namesJulian Andres Klode2020-10-261-7/+3
| | | | | | | | | We accidentally excluded virtual packages by excluding every group that had a package, but where the package had no versions. Rewrite the code so the lookup consistently uses VersionList() instead of FirstVersion and FindPkg("any") - those are all the same, and this is easier to read.
* pkgnames: Correctly set the default for AllNames to falseJulian Andres Klode2020-10-261-1/+1
| | | | | | | We passed "false" instead of false, and that apparently got cast to bool, because it's a non-null pointer. LP: #1876495
* Make map_pointer<T> typesafeJulian Andres Klode2020-02-241-2/+2
| | | | | | | | | | | 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-4/+4
| | | | | | 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.
* Apply various suggestions by cppcheckDavid Kalnischkies2019-07-081-8/+7
| | | | Reported-By: cppcheck
* cacheset: Remove simple cases of deprecated codeJulian Andres Klode2019-05-061-4/+4
| | | | | | This is missing the ones that are still actively used in cacheset.cc, we need to clean those up too, but they are obviously more tricky.
* sptr: Remove deprecated smart pointer classesJulian Andres Klode2019-02-261-1/+0
| | | | Please use the standard C++ variants instead.
* Generalize %s does not take any argumentsJulian Andres Klode2019-01-101-1/+1
| | | | | | | | This used to be "apt-cache stats does not take any arguments", but replace "apt-cache stats" with "%s" so we can reuse it for other commands. Gbp-Dch: ignore
* Support --with-source in show & search commandsDavid Kalnischkies2018-05-111-6/+1
|
* Remove obsolete RCS keywordsGuillem Jover2018-05-071-1/+0
| | | | Prompted-by: Jakub Wilk <jwilk@debian.org>
* Reformat and sort all includes with clang-formatJulian Andres Klode2017-07-121-13/+13
| | | | | | | | | | | | | 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.
* Drop cacheiterators.h includeJulian Andres Klode2017-07-121-1/+0
| | | | | Including cacheiterators.h before pkgcache.h fails because pkgcache.h depends on cacheiterators.h.
* avoid explicit types for pkg counts by autoDavid Kalnischkies2017-06-261-13/+15
| | | | | | | | | Changes nothing on the program front and as the datatypes are sufficently comparable fixes no bug either, but problems later on if we ever change the types of those and prevent us using types which are too large for the values we want to store waste (a tiny bit of) resources. Gbp-Dch: Ignore
* use +0000 instead of UTC by default as timezone in outputDavid Kalnischkies2016-07-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | All apt versions support numeric as well as 3-character timezones just fine and its actually hard to write code which doesn't "accidently" accepts it. So why change? Documenting the Date/Valid-Until fields in the Release file is easy to do in terms of referencing the datetime format used e.g. in the Debian changelogs (policy §4.4). This format specifies only the numeric timezones through, not the nowadays obsolete 3-character ones, so in the interest of least surprise we should use the same format even through it carries a small risk of regression in other clients (which encounter repositories created with apt-ftparchive). In case it is really regressing in practice, the hidden option -o APT::FTPArchive::Release::NumericTimezone=0 can be used to go back to good old UTC as timezone. The EDSP and EIPP protocols use this 'new' format, the text interface used to communicate with the acquire methods does not for compatibility reasons even if none of our methods would be effected and I doubt any other would (in these instances the timezone is 'GMT' as that is what HTTP/1.1 requires). Note that this is only true for apt talking to methods, (libapt-based) methods talking to apt will respond with the 'new' format. It is therefore strongly adviced to support both also in method input.
* look into the right textdomain for apt-utils againDavid Kalnischkies2016-05-281-2/+0
| | | | | Broken in e7e10e47476606e3b2274cf66b1e8ea74b236757 by looking always into "apt" while we ship some tools in "apt-utils"…
* apt-cache: stats: Show a table utilization as percentageJulian Andres Klode2016-01-031-0/+1
| | | | Gbp-Dch: ignore
* apt-cache: stats: Average is over used, not all, bucketsJulian Andres Klode2016-01-031-1/+1
| | | | | It does not make sense to consider empty buckets in the average, as they do not affect the lookup performance.
* drop some needlessly public declarations in libapt-privateDavid Kalnischkies2015-11-291-2/+2
| | | | Git-Dch: Ignore
* move 'unmet' handling into libapt-privateDavid Kalnischkies2015-11-291-103/+1
| | | | Git-Dch: Ignore
* use function pointers instead of weak symbols for cmdline parsingDavid Kalnischkies2015-11-291-1/+1
| | | | | | | | Passing function pointers around while working on this was very icky, but if weak symbols are too much to ask for… Reverts "do not use "-Wl,-Bsymbolic-functions" during the build to avoid breakage" aka a5fc9be36211a290a7abc3ca2a8bf98943bc1f57.
* review of new/changed translatable program stringsJustin B Rye2015-11-211-4/+4
| | | | | Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html
* revamp all tools help messagesDavid Kalnischkies2015-11-041-15/+7
| | | | | | | | | | | | | | | | The general idea is: A small paragraph on the tool itself as a description, a list of the most used (!= all) commands available in the tool, a remark where to find more information on the tool and its commands (aka: in the manpage) and finally a common block referring to even more manpages. In exchange options are completely omitted from the output as well as deprecated or obscure commands. (Better) Information about them is available in the manpages anyway and the few options which were listed before were also the least interesting ones (-o -c -q and co are hardly of interest for someone totally new looking to find info by asking for help and anyone with a bit of experience doesn't need this short list. Those would need a list of options applying to the command they call, but they are too numerous and command specific to list them sanely in this context.
* hidden support more apt-get/apt-cache commands in aptDavid Kalnischkies2015-11-041-321/+1
| | | | | | | | | | | | | | apt is supposed to be a user-friendly interface, so while these commands are usually poweruser material and therefore do not need to be shown in general introduction manpages/help messages its of no use to not allow users to use them. This includes clean, autoclean, build-dep, source, download, changelog, depends, rdepends and showsrc – it doesn't include more non-interactive commands like dump or xvcg as those are usually used by scripts if at all. Closes: 778234, 780700, 781237
* deal with --version more centrallyDavid Kalnischkies2015-11-041-14/+2
| | | | Git-Dch: Ignore
* move apts cmdline helper type into -privateDavid Kalnischkies2015-11-041-3/+2
| | | | | | | | Its not as simple as I initially thought to abstract this enough to make it globally usable, so lets not pollute global namespace with this for now. Git-Dch: Ignore
* generate commands array after config is loadedDavid Kalnischkies2015-11-041-6/+9
| | | | | | | This ensures that location strings loaded from a location specified via configuration (Dir::Locale) effect the help messages for commands. Git-Dch: Ignore
* deduplicate main methodsDavid Kalnischkies2015-11-041-17/+5
| | | | | | | | All mains pretty much do the same thing, so lets try a little harder to move the common parts into -private to have the real differences more visible. Git-Dch: Ignore
* split up help messages for simpler reuseDavid Kalnischkies2015-11-041-45/+35
| | | | | | | | | | | | | That is one huge commit with busy work only: Help messages used to be one big translateable string, which is a pain for translators and hard to reuse for us. This change there 'explodes' this single string into new string for each documented string trying hard to split up the translated messages as well. This actually restores many translations as previously adding a single command made all of the bug message fuzzy. The splitup also highlighted that its easy to forget a line, duplicate one and similar stuff. Git-Dch: Ignore
* move 'search' implementations as wellDavid Kalnischkies2015-11-041-200/+2
| | | | Git-Dch: Ignore
* centralize 'show' implementation of apt and apt-cacheDavid Kalnischkies2015-11-041-140/+2
| | | | | | | | | | The show commands have different styles in both binaries as the audience is potentially very different, but that doesn't mean we need to separate the implementation especially as they are slightly similar. This also allows us to switch between the different show versions at runtime via an option. Git-Dch: Ignore
* various changes to increase test-coverageDavid Kalnischkies2015-09-141-3/+4
| | | | | | | And of course, testing obscure things ends up showing obscure 'bugs' or better shortcomings/inconsitencies, so lets fix them with the tests. Git-Dch: Ignore
* implement dpkgs vision of interpreting pkg:<arch> dependenciesDavid Kalnischkies2015-09-141-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | How the Multi-Arch field and pkg:<arch> dependencies interact was discussed at DebConf15 in the "MultiArch BoF". dpkg and apt (among other tools like dose) had a different interpretation in certain scenarios which we resolved by agreeing on dpkg view – and this commit realizes this agreement in code. As was the case so far libapt sticks to the idea of trying to hide MultiArch as much as possible from individual frontends and instead translates it to good old SingleArch. There are certainly situations which can be improved in frontends if they know that MultiArch is upon them, but these are improvements – not necessary changes needed to unbreak a frontend. The implementation idea is simple: If we parse a dependency on foo:amd64 the dependency is formed on a package 'foo:amd64' of arch 'any'. This package is provided by package 'foo' of arch 'amd64', but not by 'foo' of arch 'i386'. Both of those foo packages provide each other through (assuming foo is M-A:foreign) to allow a dependency on 'foo' to be satisfied by either foo of amd64 or i386. Packages can also declare to provide 'foo:amd64' which is translated to providing 'foo:amd64:any' as well. This indirection over provides was chosen as the alternative would be to teach dependency resolvers how to deal with architecture specific dependencies – which violates the design idea of avoiding resolver changes, especially as architecture-specific dependencies are a cornercase with quite a few subtil rules. Handling it all over versioned provides as we already did for M-A in general seems much simpler as it just works for them. This switch to :any has actually a "surprising" benefit as well: Even frontends showing a package name via .Name() [which doesn't show the architecture] will display the "architecture" for dependencies in which it was explicitely requested, while we will not show the 'strange' :any arch in FullName(true) [= pretty-print] either. Before you had to specialcase these and by default you wouldn't get these details shown. The only identifiable disadvantage is that this complicates error reporting and handling. apt-get's ShowBroken has existing problems with virtual packages [it just shows the name without any reason], so that has to be worked on eventually. The other case is that detecting if a package is completely unknown or if it was at least referenced somewhere needs to acount for this "split" – not that it makes a practical difference which error is shown… but its one of the improvements possible.
* Add support for "apt-cache showsrc --only-source srcpkgname"Michael Vogt2015-08-181-0/+4
| | | | | Thanks: Steve Slangasek for the suggestion Closes: 695633
* Show full package records in apt-cache search -fKusanagi Kouichi2015-08-161-7/+4
| | | | | | | | | This just changes the DoSearch code to use DisplayRecord to display the record when the full record is requested. Closes: #660851 [jak@debian.org: Wrote the commit message]
* When looking if Provides match, OR them with the normal patchesJulian Andres Klode2015-08-161-1/+1
| | | | | | | Simply overriding the value caused patterns that previously matched a real package name to not match anymore. Closes: #760868
* apt-cache: Show an error if stats gets any argumentsJulian Andres Klode2015-08-141-1/+6
| | | | Closes: #153161
* Deprecate SPtrArray<T> and convert everyone to unique_ptr<T[]>Julian Andres Klode2015-08-131-3/+3
| | | | More standardization
* apt-cache: Improve translateability of the "with priority" thingJulian Andres Klode2015-08-121-2/+2
| | | | Gbp-Dch: ignore
* apt-cache: Modify policy output to use per-version pinsJulian Andres Klode2015-08-121-13/+30
| | | | Also optionally enable old output by setting APT::Policy=0.
* just-in-time creation for (implicit) ProvidesDavid Kalnischkies2015-08-101-2/+2
| | | | | | | | | | | | | | | | Expecting the worst is easy to code, but has its disadvantages e.g. by creating package structures which otherwise would have never existed. By creating the provides instead at the time a package structure is added we are well prepared for the introduction of partial architectures, massive amounts of M-A:foreign (and :allowed) and co as far as provides are concerned at least. We have something relatively similar for dependencies already. Many tests are added for both M-A states and the code cleaned to properly support implicit provides for foreign architectures and architectures we 'just' happen to parse. Git-Dch: Ignore
* hide implicit deps in apt-cache again by defaultDavid Kalnischkies2015-08-101-3/+8
| | | | | | | | | | | | | | 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.
* remove the compatibility markers for 4.13 abiDavid Kalnischkies2015-08-101-3/+1
| | | | | | | | 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
* split-up Dependency structDavid Kalnischkies2015-08-101-4/+5
| | | | | | | | | | | | | | | | | | | | | 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
* fix memory leaks reported by -fsanitizeDavid Kalnischkies2015-08-101-0/+1
| | | | | | | | Various small leaks here and there. Nothing particularily big, but still good to fix. Found by the sanitizers while running our testcases. Reported-By: gcc -fsanitize Git-Dch: Ignore
* apt-cache: Change version pin output to use per-version pinsJulian Andres Klode2015-08-101-1/+1
|
* hide Translation-* in 'apt-cache policy' outputDavid Kalnischkies2015-06-151-0/+2
| | | | | | | | | | | | | 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-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* rewrite all TFRewrite instances to use the new pkgTagSection::WriteDavid Kalnischkies2015-05-111-9/+12
| | | | | | | | | While it is mostly busywork to rewrite all instances it actually fixes bugs as the data storage used by the new method is std::string rather than a char*, the later mostly created by c_str() from a std::string which the caller has to ensure keeps in scope – something apt-ftparchive actually didn't ensure and relied on copy-on-write behavior instead which c++11 forbids and hence the new default gcc abi doesn't use it.
* stop displaying time of build in online helpJérémy Bobbio2015-03-161-3/+2
| | | | | | | | | | | | | | | | | | As part of the “reproducible builds” effort [1], we have noticed that apt could not be built reproducibly. One issue is that it uses the __DATE__ and __TIME__ macros of the C preprocessor to display the time of build in the online help. We believe this information not to be really useful to users as they can always look at the package data and metadata to figure it out. The attached patch simply removes this information. All non-documentation packages can then be built reproducibly with our current experimental framework. [David: changed the string slightly to be untranslateable as well] Closes: 774342
* various small additional tests and testcasesDavid Kalnischkies2014-11-181-2/+2
| | | | | | | | | Usually they don't provide a lot in terms of what they test, but they help in covering many lines from strictly anecdotal commands (stats, moo) and error messages, so that stuff which really needs to be tested, but isn't is better visible in coverage reports. Git-Dch: Ignore
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-01 04:40:59 +0000