<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/policy.cc, branch 1.3_rc2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.3_rc2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.3_rc2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-06-29T10:22:33Z</updated>
<entry>
<title>if conf unset, don't read / as conf/pref/sources dir</title>
<updated>2016-06-29T10:22:33Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-29T08:16:14Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=42610b9d5a95ec108b74ffbc6446542cf6b0176a'/>
<id>urn:sha1:42610b9d5a95ec108b74ffbc6446542cf6b0176a</id>
<content type='text'>
Usually these config options are set to sensible values, but if init
isn't run or the user interferes with configuration clearing or similar
the options could indeed carry an empty value, which will result in
FindDir returning a '/'. That feels kinda wrong, but as a public
interface there isn't much we can do about it and instead make it so
that we get the special file /dev/null back we know how to deal with in
such cases.
</content>
</entry>
<entry>
<title>fail instead of segfault on unreadable config files</title>
<updated>2016-05-20T07:37:24Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-05-20T07:37:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=fdf9eef4d96a18d0167708499c993e1174251e88'/>
<id>urn:sha1:fdf9eef4d96a18d0167708499c993e1174251e88</id>
<content type='text'>
The report mentions "apt list --upgradable", but there are others which
have inconsistent behavior ranging from segfaulting to doing something
with the partial (and hence incomplete) data. We had a recent report
about sources.list (#818628), this one mentions prefences, the obvious
next step is conf files… so the testcase is adapted to check for all
three in file and directory versions and run a bunch of commands each
time which should all have more or less the same behavior in such a case
(aka error out).

Closes: 824503
</content>
</entry>
<entry>
<title>policy: Remove TODO for replacing old GetCandidateVer()</title>
<updated>2016-04-25T19:50:20Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-04-25T19:50:20Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0fae1ac4bfbf62e556f1d6a316b0a576c62d4131'/>
<id>urn:sha1:0fae1ac4bfbf62e556f1d6a316b0a576c62d4131</id>
<content type='text'>
Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>policy: Get rid of old (pre-1.1) GetCandidateVer algorithm</title>
<updated>2016-04-25T19:38:09Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-04-25T14:07:28Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=71180b9889046e30b63d70882c2381d6e3e9763f'/>
<id>urn:sha1:71180b9889046e30b63d70882c2381d6e3e9763f</id>
<content type='text'>
Bye bye old friend. You're in one Ubuntu LTS release for compat
testing, now we do not need you anymore.
</content>
</entry>
<entry>
<title>restore pinning to min/max value of short</title>
<updated>2016-04-25T14:30:43Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-04-25T14:30:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=fd2e438b24f4ce153ee35a691ae5bcb7eb28cc98'/>
<id>urn:sha1:fd2e438b24f4ce153ee35a691ae5bcb7eb28cc98</id>
<content type='text'>
Broken in the previous commit (69cea1ef2cfda3c4da79fd756a8edaf2be26998e).
Adding a test and a comment to avoid future embarrassment.

Git-Dch: Ignore
Reported-By: Julian Andres Klode on IRC
</content>
</entry>
<entry>
<title>give rc-status packages a pin of -1</title>
<updated>2016-04-25T13:35:52Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-04-25T12:36:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=69cea1ef2cfda3c4da79fd756a8edaf2be26998e'/>
<id>urn:sha1:69cea1ef2cfda3c4da79fd756a8edaf2be26998e</id>
<content type='text'>
It would previously return a pin of 0, which is an invalid value, but
the intend is that versions which are only in the dpkg/status file can't
be selected for installation (= can't be a candidate) which is what a
negative pin assures.

This helps with the communication to EDSP solvers as they neither know
about the rc-state (yet) nor that they shouldn't choose this version.
Ideally they shouldn't be told about such versions at all as there is
nothing to be solved here, but we will get there eventually.
</content>
</entry>
<entry>
<title>properly parse comments in apt_preferences and deb822-style sources</title>
<updated>2016-01-02T15:20:01Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-01-02T12:27:02Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f6459e646f6fa45c34d1f13f37173ea4b92ffd5f'/>
<id>urn:sha1:f6459e646f6fa45c34d1f13f37173ea4b92ffd5f</id>
<content type='text'>
apt_preferences and deb822-style sources used the specialized class
pkgUserTagSection to deal with comments before/after a given stanza, but
it couldn't deal with comments in the stanza at all.

codesearch suggests that nobody else does and a vastely superior way of
working with potentially commented files is implemented now, so we can
officially discourage the use of the old incomplete hack class.
</content>
</entry>
<entry>
<title>apply various suggestions made by cppcheck</title>
<updated>2015-11-05T11:21:33Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-04T20:08:55Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=258b9e512c4001e806c5c0966acecd3d742ec6e9'/>
<id>urn:sha1:258b9e512c4001e806c5c0966acecd3d742ec6e9</id>
<content type='text'>
Reported-By: cppcheck
Git-Dch: Ignore
</content>
</entry>
<entry>
<title>provide public interface to hold/unhold packages</title>
<updated>2015-11-04T17:04:00Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-25T09:25:25Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b49068c566d749130e023536d54588c948c16edf'/>
<id>urn:sha1:b49068c566d749130e023536d54588c948c16edf</id>
<content type='text'>
We had this code lying around in apt-mark for a while now, but other
frontends need this (and similar) functionality as well, so its high
time that we provide a public interface in libapt for this stuff.
</content>
</entry>
<entry>
<title>avoid using global PendingError to avoid failing too often too soon</title>
<updated>2015-09-14T13:22:18Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-10T17:00:51Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=95278287f4e1eeaf5d96749d6fc9bfc53fb400d0'/>
<id>urn:sha1:95278287f4e1eeaf5d96749d6fc9bfc53fb400d0</id>
<content type='text'>
Our error reporting is historically grown into some kind of mess.
A while ago I implemented stacking for the global error which is used in
this commit now to wrap calls to functions which do not report (all)
errors via return, so that only failures in those calls cause a failure
to propergate down the chain rather than failing if anything
(potentially totally unrelated) has failed at some point in the past.

This way we can avoid stopping the entire acquire process just because a
single source produced an error for example. It also means that after
the acquire process the cache is generated – even if the acquire
process had failures – as we still have the old good data around we can and
should generate a cache for (again).

There are probably more instances of this hiding, but all these looked
like the easiest to work with and fix with reasonable (aka net-positive)
effects.
</content>
</entry>
</feed>
