<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/edsp/edspsystem.cc, branch 1.3_exp2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.3_exp2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.3_exp2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-06-08T11:07:21Z</updated>
<entry>
<title>edsp: optionally store a compressed copy of the last scenario</title>
<updated>2016-06-08T11:07:21Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-07T15:01:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=385d9f2f23057bc5808b5e013e77ba16d1c94da4'/>
<id>urn:sha1:385d9f2f23057bc5808b5e013e77ba16d1c94da4</id>
<content type='text'>
For bugreports and co it could be handy to have the scenario and all the
settings used in it around later for inspection for EDSP like protocols.
EDSP might not be the most interesting as the user can still interrupt
the process before the solution is applied and users tend to have an
opinion on the "rightness" of a solution, so it is disabled by default.
</content>
</entry>
<entry>
<title>edsp: prevent it from trying to write a cache</title>
<updated>2016-06-06T13:54:06Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-06T13:54:06Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=35f3ed061f10a25a3fb28bc988fddbb976344c4d'/>
<id>urn:sha1:35f3ed061f10a25a3fb28bc988fddbb976344c4d</id>
<content type='text'>
EDSP(-like) protocols are one-shot processes working on data which
exists only as long as they run (as they get feed via a pipe), so trying
to write a cache for it is pretty pointless, especially as it will
usually fail as the cache files tend to be owned by root, but the
process is run as a unpriviledged user (either _apt if called by root,
otherwise the user of the caller).

So this was in fact only observeable with our testcases which run as
non-root and the worst which happens is that a valid cache is overridden
with an invalid one which the next run will detect and not use.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>refactor EDSP classes for better internal reuse</title>
<updated>2016-06-05T11:15:55Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-06-05T11:05:30Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d59671c9eef322c10abba22b0257fef37979dfd4'/>
<id>urn:sha1:d59671c9eef322c10abba22b0257fef37979dfd4</id>
<content type='text'>
The classes are all marked as hidden, so changing them is no problem ABI
wise and will help with introducing protocols similar to EDSP.
The change has no observeable behavior difference, its just code
juggling.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>edspsystem.cc: include &lt;stdlib.h&gt; for mkdtemp</title>
<updated>2016-02-03T22:46:19Z</updated>
<author>
<name>Fredrik Fornwall</name>
<email>fredrik@fornwall.net</email>
</author>
<published>2015-12-07T23:48:50Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ef72d726399763446f31a07b11f30f6a726ea81a'/>
<id>urn:sha1:ef72d726399763446f31a07b11f30f6a726ea81a</id>
<content type='text'>
Include &lt;stdlib.h&gt; to ensure that mkdtemp(3) is defined to improve
general portability and fix a specific build failure on Android.

Closes: #807367
</content>
</entry>
<entry>
<title>wrap every unlink call to check for != /dev/null</title>
<updated>2015-11-04T17:42:28Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-11-02T17:49:52Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ce1f3a2c616b86da657c1c796efa5f4d18c30c39'/>
<id>urn:sha1:ce1f3a2c616b86da657c1c796efa5f4d18c30c39</id>
<content type='text'>
Unlinking /dev/null is bad, we shouldn't do that. Also, we should print
at least a warning if we tried to unlink a file but didn't manage to
pull it of (ignoring the case were the file is /dev/null or doesn't
exist in the first place).

This got triggered by a relatively unlikely to cause problem in
pkgAcquire::Worker::PrepareFiles which would while temporary
uncompressed files (which are set to keep compressed) figure out that to
files are the same and prepare for sharing by deleting them. Bad move.
That also shows why not printing a warning is a bad idea as this hide
the error for in non-root test runs.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>use a less generic special trigger filename for stdin</title>
<updated>2015-09-14T13:22:18Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-10T16:46:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7f58427b9584686f80cd5eccfdd02c1ace75518a'/>
<id>urn:sha1:7f58427b9584686f80cd5eccfdd02c1ace75518a</id>
<content type='text'>
Git-Dch: Ignore
</content>
</entry>
<entry>
<title>implement autobit and pinning in EDSP solver 'apt'</title>
<updated>2015-09-14T13:22:18Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-09-08T20:14:11Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=188a6fcf4f13df1fd362a0aff27a23493ddd1ec5'/>
<id>urn:sha1:188a6fcf4f13df1fd362a0aff27a23493ddd1ec5</id>
<content type='text'>
The parser creates a preferences as well as an extended states file
based on the EDSP scenario file, which isn't the most efficient way of
dealing with this as thes text files have to be parsed again by another
layer of the code, but it needs the least changes and works good enough
for now. The 'apt' solver is in the end just a test solver like dump.
</content>
</entry>
<entry>
<title>Cleanup includes after running iwyu</title>
<updated>2015-08-17T10:01:45Z</updated>
<author>
<name>Michael Vogt</name>
<email>mvo@debian.org</email>
</author>
<published>2015-08-17T10:01:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=88a8975f156e452d9f3ebe76822b236e8962ebba'/>
<id>urn:sha1:88a8975f156e452d9f3ebe76822b236e8962ebba</id>
<content type='text'>
</content>
</entry>
<entry>
<title>elimate duplicated code in pkgIndexFile subclasses</title>
<updated>2015-08-10T15:27:59Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-07-20T08:17:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=c9443c01208377f0cba9706412ea3a98ad97b56d'/>
<id>urn:sha1:c9443c01208377f0cba9706412ea3a98ad97b56d</id>
<content type='text'>
Trade deduplication of code for a bunch of new virtuals, so it is
actually visible how the different indexes behave cleaning up the
interface at large in the process.

Git-Dch: Ignore
</content>
</entry>
<entry>
<title>add volatile sources support in libapt-pkg</title>
<updated>2015-08-10T15:27:59Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2015-07-18T16:03:54Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5465192b9aeb1ccea778950ccf2d1b7b32f2cd91'/>
<id>urn:sha1:5465192b9aeb1ccea778950ccf2d1b7b32f2cd91</id>
<content type='text'>
Sources are usually defined in sources.list (and co) and are pretty
stable, but once in a while a frontend might want to add an additional
"source" like a local .deb file to install this package (No support for
'real' sources being added this way as this is a multistep process).

We had a hack in place to allow apt-get and apt to pull this of for a
short while now, but other frontends are either left in the cold by this
and/or the code for it looks dirty with FIXMEs plastering it and has on
top of this also some problems (like including these 'volatile' sources
in the srcpkgcache.bin file).

So the biggest part in this commit is actually the rewrite of the cache
generation as it is now potentially a three step process. The biggest
problem with adding support now through is that this makes a bunch of
previously mostly unusable by externs and therefore hidden classes
public, so a bit of further tuneing on this now public API is in order…
</content>
</entry>
</feed>
