summaryrefslogtreecommitdiff
path: root/cmdline/apt-cache.cc
AgeCommit message (Collapse)Author
2019-05-06cacheset: Remove simple cases of deprecated codeJulian Andres Klode
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.
2019-02-26sptr: Remove deprecated smart pointer classesJulian Andres Klode
Please use the standard C++ variants instead.
2019-01-10Generalize %s does not take any argumentsJulian Andres Klode
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
2018-05-11Support --with-source in show & search commandsDavid Kalnischkies
2018-05-07Remove obsolete RCS keywordsGuillem Jover
Prompted-by: Jakub Wilk <jwilk@debian.org>
2017-07-12Reformat and sort all includes with clang-formatJulian Andres Klode
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.
2017-07-12Drop cacheiterators.h includeJulian Andres Klode
Including cacheiterators.h before pkgcache.h fails because pkgcache.h depends on cacheiterators.h.
2017-06-26avoid explicit types for pkg counts by autoDavid Kalnischkies
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
2016-07-02use +0000 instead of UTC by default as timezone in outputDavid Kalnischkies
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.
2016-05-28look into the right textdomain for apt-utils againDavid Kalnischkies
Broken in e7e10e47476606e3b2274cf66b1e8ea74b236757 by looking always into "apt" while we ship some tools in "apt-utils"…
2016-01-03apt-cache: stats: Show a table utilization as percentageJulian Andres Klode
Gbp-Dch: ignore
2016-01-03apt-cache: stats: Average is over used, not all, bucketsJulian Andres Klode
It does not make sense to consider empty buckets in the average, as they do not affect the lookup performance.
2015-11-29drop some needlessly public declarations in libapt-privateDavid Kalnischkies
Git-Dch: Ignore
2015-11-29move 'unmet' handling into libapt-privateDavid Kalnischkies
Git-Dch: Ignore
2015-11-29use function pointers instead of weak symbols for cmdline parsingDavid Kalnischkies
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.
2015-11-21review of new/changed translatable program stringsJustin B Rye
Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html
2015-11-04revamp all tools help messagesDavid Kalnischkies
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.
2015-11-04hidden support more apt-get/apt-cache commands in aptDavid Kalnischkies
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
2015-11-04deal with --version more centrallyDavid Kalnischkies
Git-Dch: Ignore
2015-11-04move apts cmdline helper type into -privateDavid Kalnischkies
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
2015-11-04generate commands array after config is loadedDavid Kalnischkies
This ensures that location strings loaded from a location specified via configuration (Dir::Locale) effect the help messages for commands. Git-Dch: Ignore
2015-11-04deduplicate main methodsDavid Kalnischkies
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
2015-11-04split up help messages for simpler reuseDavid Kalnischkies
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
2015-11-04move 'search' implementations as wellDavid Kalnischkies
Git-Dch: Ignore
2015-11-04centralize 'show' implementation of apt and apt-cacheDavid Kalnischkies
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
2015-09-14various changes to increase test-coverageDavid Kalnischkies
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
2015-09-14implement dpkgs vision of interpreting pkg:<arch> dependenciesDavid Kalnischkies
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.
2015-08-18Add support for "apt-cache showsrc --only-source srcpkgname"Michael Vogt
Thanks: Steve Slangasek for the suggestion Closes: 695633
2015-08-16Show full package records in apt-cache search -fKusanagi Kouichi
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]
2015-08-16When looking if Provides match, OR them with the normal patchesJulian Andres Klode
Simply overriding the value caused patterns that previously matched a real package name to not match anymore. Closes: #760868
2015-08-14apt-cache: Show an error if stats gets any argumentsJulian Andres Klode
Closes: #153161
2015-08-13Deprecate SPtrArray<T> and convert everyone to unique_ptr<T[]>Julian Andres Klode
More standardization
2015-08-12apt-cache: Improve translateability of the "with priority" thingJulian Andres Klode
Gbp-Dch: ignore
2015-08-12apt-cache: Modify policy output to use per-version pinsJulian Andres Klode
Also optionally enable old output by setting APT::Policy=0.
2015-08-10just-in-time creation for (implicit) ProvidesDavid Kalnischkies
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
2015-08-10hide implicit deps in apt-cache again by defaultDavid Kalnischkies
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.
2015-08-10remove the compatibility markers for 4.13 abiDavid Kalnischkies
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
2015-08-10split-up Dependency structDavid Kalnischkies
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
2015-08-10fix memory leaks reported by -fsanitizeDavid Kalnischkies
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
2015-08-10apt-cache: Change version pin output to use per-version pinsJulian Andres Klode
2015-06-15hide Translation-* in 'apt-cache policy' outputDavid Kalnischkies
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.
2015-06-12store Release files data in the CacheDavid Kalnischkies
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.
2015-05-11rewrite all TFRewrite instances to use the new pkgTagSection::WriteDavid Kalnischkies
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.
2015-03-16stop displaying time of build in online helpJérémy Bobbio
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
2014-11-18various small additional tests and testcasesDavid Kalnischkies
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
2014-11-09use the same code to detect quiet setting in all toolsDavid Kalnischkies
Git-Dch: Ignore
2014-11-09streamline display of --help in all toolsDavid Kalnischkies
By convention, if I run a tool with --help or --version I expect it to exit successfully with the usage, while if I do call it wrong (like without any parameters) I expect the usage message shown with a non-zero exit.
2014-11-08guard pkg/grp hashtable creation changesDavid Kalnischkies
The change itself is no problem ABI wise, but the remove of the old undynamic hashtables is, so we bring it back for older abis and happily use the now available free space to backport more recent additions like the dynamic hashtable itself. Git-Dch: Ignore
2014-11-08guard ABI changes for SourcePkg/Ver in pkgCacheDavid Kalnischkies
Git-Dch: Ignore
2014-09-27store source name and version in binary cacheDavid Kalnischkies
Accessing the package records to acquire this information is pretty costly, so that information wasn't used so far in many places. The most noticeable user by far is EDSP at the moment, but there are ideas to change that which this commit tries to enable.