<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/deb, 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-08-17T12:12:25Z</updated>
<entry>
<title>add --with-source option and Packages/Sources support</title>
<updated>2016-08-17T12:12:25Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-16T18:08:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8bd823d0a1f7e08ad94a7110bb118f73348133a1'/>
<id>urn:sha1:8bd823d0a1f7e08ad94a7110bb118f73348133a1</id>
<content type='text'>
We support "./foobar.deb" as a way to install a deb file directly.
Recently .changes files were added. This highlights a problem as you
can't add the changes file without also trying to install all of them.
Now, it could also be handy to add entire Packages/Sources files to
perhaps get a bunch of packages in without installing them all
implicitly.

This commit introduces --with-source which allows to add *.deb, *.changes,
*.dsc, source-dirs, Packages &amp; Sources files (the later can also be
compressed) without also installing them.
</content>
</entry>
<entry>
<title>default to Dir=/ in dpkg/status file finding magic</title>
<updated>2016-08-17T05:55:46Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-13T13:55:52Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5586b8882fda5f099d65a91f362c14c9d7e1b4ac'/>
<id>urn:sha1:5586b8882fda5f099d65a91f362c14c9d7e1b4ac</id>
<content type='text'>
Seen in cme #833656 if Dir isn't set (yet) we end up later absoluting a
path which was supposed to be absolute already, so if Dir is empty we
assume it to be '/' instead. In practice this is a bug in the software
using libapt, but for maxium compatibility lets explicitly set the
default value here to be safe.

Reported-By: Paul Wise &lt;pabs@debian.org&gt;
Inspired-By: Brendan O'Dea &lt;bod@debian.org&gt;
Fixes-Regression: 475f75506db48a7fa90711fce4ed129f6a14cc9a
Shadows-Bug: #833656
</content>
</entry>
<entry>
<title>disable explicit configuration of all packages at the end</title>
<updated>2016-08-10T21:51:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-28T07:13:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=28557f94578602f9ce0011501a2259bd98ab0688'/>
<id>urn:sha1:28557f94578602f9ce0011501a2259bd98ab0688</id>
<content type='text'>
With b4450f1dd6bca537e60406b2383ab154a3e1485f we dropped what we
calculated here later on and now that we don't need it in the meantime
either we can just skip the busy work by default and expect dpkg to do
the right thing dropping also our little "last explicit configures"
removal trick introduced in b4450f1dd6bca537e60406b2383ab154a3e1485f.

This enables the last of a bunch of previously experimental options,
some of them existing still, but are very special and hence not really
worth documenting anymore (especially as it would need to be rewritten
now entirely) which is why the documentation is nearly completely
dropped.

The order of configuration stanzas in the simulation code changes
slightly as it isn't concerning itself with finding the 'right' order,
but any order is valid anyhow as long as the entire set happens in the
same call.
</content>
</entry>
<entry>
<title>simulate all package manager actions explicitly</title>
<updated>2016-08-10T21:51:34Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-28T09:43:36Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4326680d2ed23d597f45ca8872a7054368560acc'/>
<id>urn:sha1:4326680d2ed23d597f45ca8872a7054368560acc</id>
<content type='text'>
If a planner lets actions to be figured out by dpkg in pending calls
these actions aren't mentioned in a simulation. While that might be
a good thing for debugging, it would be a change in behavior and
especially if a planner avoids explicit removals could be confusing for
users. As such we perform the same 'trick' as in the dpkg implementation
by performing explicitly what would be done by the pending calls.

To save us some work and avoid desyncs we perform a layer violation by
using deb/ code in the generic simulation – and further we perform ugly
dynamic_cast to avoid breaking the ABI for nothing; aptitude is the only
other user of the simulation class according to codesearch.d.n and for
that our little trick works. It just isn't working if you happen to
extend pkgSimulate or otherwise manage to call the protected Go methods
directly – which isn't very realistic/practical.
</content>
</entry>
<entry>
<title>try to avoid removal of crossgraded packages</title>
<updated>2016-08-10T21:51:34Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-25T14:36:53Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=83e5cffc2015aa809acac84737756d292d7bf106'/>
<id>urn:sha1:83e5cffc2015aa809acac84737756d292d7bf106</id>
<content type='text'>
The user has to approve the removal of a crossgraded package as it might
be needed to remove it (temporarily) in the process, but in most cases
we can happily avoid it and let dpkg unpack over it skipping the
remove. This has some effects on progress reporting and how deal with
selections through which makes this a tiny bit complicated.
</content>
</entry>
<entry>
<title>ensure all removes are reported to hook scripts</title>
<updated>2016-08-10T21:18:04Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-24T17:00:08Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=bfc0933abedcd57e0a5bd07e282f3a50ba1fa5b2'/>
<id>urn:sha1:bfc0933abedcd57e0a5bd07e282f3a50ba1fa5b2</id>
<content type='text'>
Same reason and implementation as for configure.
</content>
</entry>
<entry>
<title>ensure all configures are reported to hook scripts</title>
<updated>2016-08-10T21:18:04Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-24T09:52:04Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9ffbac99e52c91182ed8ff8678a994626b194e69'/>
<id>urn:sha1:9ffbac99e52c91182ed8ff8678a994626b194e69</id>
<content type='text'>
A planner might not explicitly configure all packages, but we need to
know all packages which will be configured for progress reporting and to
tell the hook scripts about them as they rely on this for their own
functionality.
</content>
</entry>
<entry>
<title>don't purge directly, but remove and do purge at the end</title>
<updated>2016-08-10T21:18:04Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-21T16:46:34Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7ec343309b7bc6001b465c870609b3c570026149'/>
<id>urn:sha1:7ec343309b7bc6001b465c870609b3c570026149</id>
<content type='text'>
If we want a package to be purged from the system tell dpkg in the
ordering (if it has to touch it explicitly) to remove it and cover the
purging of the config files at the end with a --purge --pending call.

That should help packages move conffiles around between packages
correctly even if the user is purging packages directly in big actions
like dist-upgrades involving many packages.
</content>
</entry>
<entry>
<title>call dpkg with --no-triggers by default</title>
<updated>2016-08-10T21:18:04Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-21T14:33:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0dd19915f44df0048d594d527797c62ab6195cc6'/>
<id>urn:sha1:0dd19915f44df0048d594d527797c62ab6195cc6</id>
<content type='text'>
Implemented a long while ago now with relatively good progress reporting
involving triggers is a good time to try delaying the execution of
triggers across dpkg invocations finally by default.

Note: The bugreport talks also about 'smarter' configuration which is a
much bigger part and approached from multiple directions, but doesn't
really involve triggers per-se so considering it decoupled should help
in getting it done…

Closes: #626599
</content>
</entry>
<entry>
<title>select remove/purge packages early on for dpkg</title>
<updated>2016-08-10T21:18:04Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-07-08T07:40:46Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e7d4e0cf4f6d79810e4b4e7de505729e759213dd'/>
<id>urn:sha1:e7d4e0cf4f6d79810e4b4e7de505729e759213dd</id>
<content type='text'>
Telling dpkg early on that we are going to remove these packages later
helps it with auto-deconfiguration decisions and its another area where
a planner can ignore the nitty gritty details and let dpkg decide the
course of action if there are no special requirements.
</content>
</entry>
</feed>
