summaryrefslogtreecommitdiff
path: root/debian/libapt-pkg5.0.symbols
AgeCommit message (Collapse)Author
2019-08-17This is 2016 and APT already requires use of mmap.Jay Freeman (saurik)
2018-08-20Update symbolsJulian Andres Klode
2017-12-13update libapt-pkg symbols fileDavid Kalnischkies
Beside adding the relatively new Item::Proxy method we are also slightly preparing for gcc-8.
2017-08-17debian: Update symbols for libapt-pkg5.0Julian Andres Klode
The version is probably wrong for most, but oh well, let's just pretend we are introducing them now.
2017-08-17Handle GCC 7 std::string operator ABI breakJulian Andres Klode
We now require gcc 7 on the packaging side, and add an appropriate symbol to our symbols file. Also adjust prepare-release to ignore g++ version requirements when setting up build dependencies on CI. Closes: #871275
2017-01-17Update symbols file for changes in 1.3.1, 1.4~beta{1,3,4}Julian Andres Klode
This is very important stuff, especially for the ParseDepends thingy as otherwise a new python-apt build would always require the apt it was built against instead of 1.4~beta3.
2016-08-29Add new symbols to symbols fileJulian Andres Klode
There are some optional symbols missing now, but let's keep them in for now, maybe they reappear/still exist on other platforms. The newly added ones actually appeared in older versions already, but there's no huge gain in finding out when precisely we added them.
2016-08-06CMake: debian: Switch packaging over to CMake and dh 9Julian Andres Klode
This new packaging is much easier to read, although the duplication in the install files is a bit annoying. We should probably also get rid of the movefiles for solvers, planners, and https method; but then we have to keep track of which methods exist in the apt package. Another disadvantage is that building only the documentation packages also requires building the code, as there's no way to turn off code building in the project.
2016-06-04edsp: use a stanza based interface for solution writingDavid Kalnischkies
EDSP had a WriteSolution method to write out the entire solution based on the inspection of a given pkgDepCache, but that is rather inflexible both for EDSP itself and for other EDSP like-protocols. It seems better to use a smaller scope in printing just a single stanza based on a given version as there is more reuse potential.
2016-06-01Pass -fvisibility-inlines-hidden to g++Julian Andres Klode
This reduces the number of symbols by about 10%. Unfortunately, it does not seem to cover all the weird std::vector and friend template expansions. ABI should not brake due to that change: It was never specified before whether an inline symbol was exported or not; so no library could rely on its presence. Instead, the symbols were exported in each library/program needing it and and then merged into a common one by the dynamic linker. Also update the symbol files to account for the removed symbols.
2016-06-01Add some more symbols to libapt-pkg5.0.symbolsJulian Andres Klode
David added some more when he changed the output format for numbers. Gbp-Dch: ignore
2016-05-20update symbols fileDavid Kalnischkies
2016-03-24Update symbols fileJulian Andres Klode
2016-01-14update symbols fileDavid Kalnischkies
git-Dch: Ignore
2015-12-13update symbols files to 1.1.4 state of affairsDavid Kalnischkies
2015-11-27update arch-specific symbols in symbols fileDavid Kalnischkies
Git-Dch: Ignore
2015-11-19update libapt-{pkg,inst} symbols filesDavid Kalnischkies
2015-10-30orderlist: Replace qsort() by thread-safe std::sort()Julian Andres Klode
Gbp-Dch: ignore
2015-10-30algorithms: Replace qsort() by thread-safe std::sort()Julian Andres Klode
Gbp-Dch: ignore
2015-08-10change to libapt-pkg abi 5.0 with versioned symbolsDavid Kalnischkies
We changed an aweful lot of stuff, so 5.0 is properly better than 4.X as a semantic version and as we are at it lets add some trivial symbol versioning as well: We just mark all exported symbols with the same version for now. This isn't really the proper thing to do as if we add symbols in later versions (with the same abi) they will get the same symbols version, but our .symbols file will protect us from the problems arising from this as it will ensure that a package acutally depends on a version of the abi high enough to include the symbol.