summaryrefslogtreecommitdiff
path: root/debian/libapt-pkg5.0.symbols
Commit message (Collapse)AuthorAgeFilesLines
* debian: Update symbols for libapt-pkg5.0Julian Andres Klode2017-08-171-0/+20
| | | | | The version is probably wrong for most, but oh well, let's just pretend we are introducing them now.
* Handle GCC 7 std::string operator ABI breakJulian Andres Klode2017-08-171-0/+1
| | | | | | | | | | 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
* Update symbols file for changes in 1.3.1, 1.4~beta{1,3,4}Julian Andres Klode2017-01-171-0/+6
| | | | | | 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.
* Add new symbols to symbols fileJulian Andres Klode2016-08-291-0/+12
| | | | | | | | | | 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.
* CMake: debian: Switch packaging over to CMake and dh 9Julian Andres Klode2016-08-061-4/+4
| | | | | | | | | | | 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.
* edsp: use a stanza based interface for solution writingDavid Kalnischkies2016-06-041-1/+1
| | | | | | | | 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.
* Pass -fvisibility-inlines-hidden to g++Julian Andres Klode2016-06-011-121/+0
| | | | | | | | | | | | | | 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.
* Add some more symbols to libapt-pkg5.0.symbolsJulian Andres Klode2016-06-011-0/+4
| | | | | | | David added some more when he changed the output format for numbers. Gbp-Dch: ignore
* update symbols fileDavid Kalnischkies2016-05-201-1/+14
|
* Update symbols fileJulian Andres Klode2016-03-241-1/+14
|
* update symbols fileDavid Kalnischkies2016-01-141-0/+6
| | | | git-Dch: Ignore
* update symbols files to 1.1.4 state of affairsDavid Kalnischkies2015-12-131-0/+5
|
* update arch-specific symbols in symbols fileDavid Kalnischkies2015-11-271-11/+17
| | | | Git-Dch: Ignore
* update libapt-{pkg,inst} symbols filesDavid Kalnischkies2015-11-191-32/+87
|
* orderlist: Replace qsort() by thread-safe std::sort()Julian Andres Klode2015-10-301-1/+0
| | | | Gbp-Dch: ignore
* algorithms: Replace qsort() by thread-safe std::sort()Julian Andres Klode2015-10-301-1/+0
| | | | Gbp-Dch: ignore
* change to libapt-pkg abi 5.0 with versioned symbolsDavid Kalnischkies2015-08-101-0/+1503
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.