<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/acquire-item.h, branch 1.2.3</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.2.3</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.2.3'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-01-08T14:40:01Z</updated>
<entry>
<title>keep compressed indexes in a low-cost format</title>
<updated>2016-01-08T14:40:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-01-07T19:32:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0179cfa83cf0042235eda41db7f35c420781c63e'/>
<id>urn:sha1:0179cfa83cf0042235eda41db7f35c420781c63e</id>
<content type='text'>
Downloading and storing are two different operations were different
compression types can be preferred. For downloading we provide the
choice via Acquire::CompressionTypes::Order as there is a choice to
be made between download size and speed – and limited by whats available
in the repository.

Storage on the other hand has all compressions currently supported by
apt available and to reduce runtime of tools accessing these files the
compression type should be a low-cost format in terms of decompression.

apt traditionally stores its indexes uncompressed on disk, but has
options to keep them compressed. Now that apt downloads additional files
we also deal with files which simply can't be stored uncompressed as
they are just too big (like Contents for apt-file). Traditionally they
are downloaded in a low-cost format (gz) as repositories do not provide
other formats, but there might be even lower-cost formats and for
download we could introduce higher-cost in the repositories.

Downloading an entire index potentially requires recompression to
another format, so an update takes potentially longer – but big files
are usually updated via pdiffs which has to de- and re-compress anyhow
and does it on the fly anyhow, so there is no extra time needed and in
general it seems to be benefitial to invest the time in update to save
time later on file access.
</content>
</entry>
<entry>
<title>allow pdiff bootstrap from all supported compressors</title>
<updated>2016-01-08T14:40:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-01-05T23:05:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4e3c5633b1e74b4f58b95f339cfbbf4cbf21ab3e'/>
<id>urn:sha1:4e3c5633b1e74b4f58b95f339cfbbf4cbf21ab3e</id>
<content type='text'>
There is no reason to enforce that the file we start the bootstrap with
is compressed with a compressor which is available online. This allows
us to change the on-disk format as well as deals with repositories
adding/removing support for a specific compressor.
</content>
</entry>
<entry>
<title>use @CHANGEPATH@ as placeholder in changelog URI templates</title>
<updated>2015-12-02T11:59:23Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-12-02T11:43:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=430481e794a3fa2e75022c67e129b54d192ad54c'/>
<id>urn:sha1:430481e794a3fa2e75022c67e129b54d192ad54c</id>
<content type='text'>
This should make it more obvious that CHANGEPATH is a placeholder which
apt will replace with a package specific path rather than a string
constant.

Mail-Reference: &lt;87d1upgvaf.fsf@deep-thought.43-1.org&gt;
Mail-Archive: https://lists.debian.org/debian-dak/2015/12/msg00005.html
</content>
</entry>
<entry>
<title>add messages to our deprecation warnings in libapt</title>
<updated>2015-11-27T14:40:47Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-27T14:40:47Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5dd00edbcf702cac1ea22392796c65881a8ef6f9'/>
<id>urn:sha1:5dd00edbcf702cac1ea22392796c65881a8ef6f9</id>
<content type='text'>
Git-Dch: Ignore
</content>
</entry>
<entry>
<title>implement PDiff patching for compressed files</title>
<updated>2015-08-28T17:26:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-08-28T17:26:44Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d7a51997c30b2098bb60b3397095ec58ec825303'/>
<id>urn:sha1:d7a51997c30b2098bb60b3397095ec58ec825303</id>
<content type='text'>
Some additional files like 'Contents' are very big and should therefore
kept compressed on the disk, which apt-file did in the past. It also
implemented pdiff patching of these files by un- and recompressing these
files on-the-fly, with this commit we can do the same – but we can do
this in both pdiff patching styles (client and server merging) and
secured by hashes.

Hashes are in so far slightly complicated as we can't compare the hashes
of the compressed files as we might compress them differently than the
server would (different compressor versions, options, …), so we must
compare the hashes of the uncompressed content.

While this commit has changes in public headers, the classes it changes
are marked as hidden, so nobody can use them directly, which means the
ABI break is internal only.
</content>
</entry>
<entry>
<title>enhance "hit paywall" error message to mention the probable cause</title>
<updated>2015-08-10T15:27:59Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-08-09T15:40:57Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=dd676dc71e31c20f66d5b9d9ac1c5a4c8883cd79'/>
<id>urn:sha1:dd676dc71e31c20f66d5b9d9ac1c5a4c8883cd79</id>
<content type='text'>
Reporting errors from Done() is bad for progress reporting and such, so
factoring this out is a good idea and we start with moving the supposed-
to-be clearsigned file isn't clearsigned out first – improving the error
message in the process as we use the same message for a similar case
(NODATA) as this is what I have to look at with the venue wifi at
DebCamp and the old errormessage doesn't really say anything.
</content>
</entry>
<entry>
<title>add c++11 override marker to overridden methods</title>
<updated>2015-08-10T15:27:17Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-07-08T22:35:40Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=3b3028467ceccca0b73a8f53051c0fa4de313111'/>
<id>urn:sha1:3b3028467ceccca0b73a8f53051c0fa4de313111</id>
<content type='text'>
C++11 adds the 'override' specifier to mark that a method is overriding
a base class method and error out if not. We hide it in the APT_OVERRIDE
macro to ensure that we keep compiling in pre-c++11 standards.

Reported-By: clang-modernize -add-override -override-macros
Git-Dch: Ignore
</content>
</entry>
<entry>
<title>remove the longtime deprecated vendor{,list} stuff</title>
<updated>2015-08-10T15:25:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-06-24T20:13:51Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=76b580bed96aaf0174ca81ba8ed2c4b54226ad85'/>
<id>urn:sha1:76b580bed96aaf0174ca81ba8ed2c4b54226ad85</id>
<content type='text'>
History suggests that this comes from an earlier apt-secure
implementation, but never really became a thing, totally unused and
marked as deprecated for "ages" now. Especially as it did nothing even
if it would have been used (libapt itself didn't use it at all).
</content>
</entry>
<entry>
<title>implement Signed-By option for sources.list</title>
<updated>2015-08-10T15:25:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-06-24T17:31:22Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b0d408547734100bf86781615f546487ecf390d9'/>
<id>urn:sha1:b0d408547734100bf86781615f546487ecf390d9</id>
<content type='text'>
Limits which key(s) can be used to sign a repository. Not immensely useful
from a security perspective all by itself, but if the user has
additional measures in place to confine a repository (like pinning) an
attacker who gets the key for such a repository is limited to its
potential and can't use the key to sign its attacks for an other (maybe
less limited) repository… (yes, this is as weak as it sounds, but having
the capability might come in handy for implementing other stuff later).
</content>
</entry>
<entry>
<title>merge indexRecords into metaIndex</title>
<updated>2015-08-10T15:25:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-06-23T13:16:08Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5ad0096a4e19e191b59634e8a8817995ec4045ad'/>
<id>urn:sha1:5ad0096a4e19e191b59634e8a8817995ec4045ad</id>
<content type='text'>
indexRecords was used to parse the Release file – mostly the hashes –
while metaIndex deals with downloading the Release file, storing all
indexes coming from this release and … parsing the Release file, but
this time mostly for the other fields.

That wasn't a problem in metaIndex as this was done in the type specific
subclass, but indexRecords while allowing to override the parsing method
did expect by default a specific format.

APT isn't really supporting different types at the moment, but this is
a violation of the abstraction we have everywhere else and, which is the
actual reason for this merge: Options e.g. coming from the sources.list
come to metaIndex naturally, which needs to wrap them up and bring them
into indexRecords, so the acquire system is told about it as they don't
get to see the metaIndex, but they don't really belong in indexRecords
as this is just for storing data loaded from the Release file… the
result is a complete mess.

I am not saying it is a lot prettier after the merge, but at least
adding new options is now slightly easier and there is just one place
responsible for parsing the Release file. That can't hurt.
</content>
</entry>
</feed>
