<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/interactive-helper/testkeep.cc, branch main</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=main</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2024-11-11T11:30:01Z</updated>
<entry>
<title>Fix keeping back removals of obsolete packages</title>
<updated>2024-11-11T11:30:01Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2024-09-05T12:56:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=49d3d6b2c3dbc0d30e46131dd288f4e106ea2fe6'/>
<id>urn:sha1:49d3d6b2c3dbc0d30e46131dd288f4e106ea2fe6</id>
<content type='text'>
ResolveByKeepInternal() inadvertently considered packages that were
marked for removals as not being possible to keep back, but that's
not true, all they need is to have a currently installed version.

The test case is a bit awkward to construct because our upgrade code
doesn't get into a place where this happens that we know off. Or maybe
it does with phased upgrades, but here we simplify this by using a
helper binary that dumps state, marks for removal, and then calls
ResolveByKeep and checks the removal is undone.

LP: #2078720
</content>
</entry>
</feed>
