<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/debian/libapt-pkg5.0.install.in, branch 2.3.0</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.3.0</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.3.0'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-08-06T20:36:02Z</updated>
<entry>
<title>CMake: debian: Switch packaging over to CMake and dh 9</title>
<updated>2016-08-06T20:36:02Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-08-06T19:40:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e825742bbbbe99b99d525a3b34832b25a7396c84'/>
<id>urn:sha1:e825742bbbbe99b99d525a3b34832b25a7396c84</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>change to libapt-pkg abi 5.0 with versioned symbols</title>
<updated>2015-08-10T15:27:59Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-08-10T09:08:35Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ae97af1fdf726a0e7e553b2fb5734b6e09a088d0'/>
<id>urn:sha1:ae97af1fdf726a0e7e553b2fb5734b6e09a088d0</id>
<content type='text'>
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.
</content>
</entry>
</feed>
