<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/depcache.cc, branch 2.5.1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.5.1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.5.1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2022-04-01T12:16:19Z</updated>
<entry>
<title>Use pkgTagSection::Key in more places in src:apt</title>
<updated>2022-04-01T12:16:19Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-04-01T11:45:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=472376be6818b5ea43250abcbecfcab53b4a729a'/>
<id>urn:sha1:472376be6818b5ea43250abcbecfcab53b4a729a</id>
<content type='text'>
The speed critical paths were converted earlier, but the remaining
could benefit a tiny bit from this as well especially as we have the
facility now available and can therefore brush up the code in various
places in the process as well.

Also takes the time to add the hidden Exists method advertised in
the headers, but previously not implemented.
</content>
</entry>
<entry>
<title>Avoid using unqualified make_pair potentially triggering ftbfs</title>
<updated>2022-03-21T01:57:34Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-03-20T14:08:18Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a0e16ddd7b274bf6b1383873315020f215e6f67a'/>
<id>urn:sha1:a0e16ddd7b274bf6b1383873315020f215e6f67a</id>
<content type='text'>
If the includes are slightly changed, we end with an error here:
apt/apt-pkg/depcache.cc:2059:31: error: ‘make_pair’ was not declared in this scope; did you mean ‘std::make_pair’?

Yes, we mean std::make_pair, but we can avoid the explicit call
altogether by using emplace_back instead of push_back.
</content>
</entry>
<entry>
<title>Spelling fixes</title>
<updated>2021-11-27T10:22:38Z</updated>
<author>
<name>Ville Skyttä</name>
<email>ville.skytta@iki.fi</email>
</author>
<published>2021-11-03T22:08:07Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=01eed4234440d82fc52c8186cf4268517bcd28bc'/>
<id>urn:sha1:01eed4234440d82fc52c8186cf4268517bcd28bc</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Do not remove Essential/Protected due to dependencies</title>
<updated>2021-11-17T16:32:18Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-11-17T15:29:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=891efe3b201a104445ea723a3a5b9b434a78c364'/>
<id>urn:sha1:891efe3b201a104445ea723a3a5b9b434a78c364</id>
<content type='text'>
Suggesting the removal of Essential and Protected packages as a
solution leads to situations where YouTubers end up removing their
desktop.

Let's not remove such packages ourselves.
</content>
</entry>
<entry>
<title>Increase recursion limits from 100 to 3000</title>
<updated>2021-08-29T12:23:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-08-29T11:50:31Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5f6bbfa53c32ec30aff6a2bc8c412616049eab18'/>
<id>urn:sha1:5f6bbfa53c32ec30aff6a2bc8c412616049eab18</id>
<content type='text'>
If you install dpkg on an empty status file with all recommends and
suggests apt wants to install 4000+ packages. The deepest chain
seemingly being 236 steps long. And dpkg isn't even the worst (~259).

That is a problem as libapt has a hardcoded recursion limit for
MarkInstall and friends … set to 100. We are saved by the fact that
chains without suggests are much shorter (dpkg has 5, max seems ~43),
but I ignored Conflicts in these chains, which typically trigger
upgrades, so if two of the worst are chained together we suddenly get
dangerously close to the limit still.

So, lets just increase the limit into oblivion as it is really just a
safety measure we should not be running into to begin with. MarkPackage
was running years without it after all. 3000 is picked as a nice number
as any other and because it is roughly the half of the stack crashs I
saw previously in this branch.
</content>
</entry>
<entry>
<title>Stop autoremover from endlessly exploring cyclic providers</title>
<updated>2021-08-28T20:21:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-08-28T13:55:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=c7e368aafe099dcd966cf5994ae7fb418d268278'/>
<id>urn:sha1:c7e368aafe099dcd966cf5994ae7fb418d268278</id>
<content type='text'>
fullyExplored is needed to keep track of having explored all providers
of a package name, while Marked is tracking if we have explored a given
real package (along its chosen version), so we should stop MarkPackage
from exploring a (real) package if it is marked and let fullyExplored
only guard the looping over the individual dependencies.

The testcase is deceptively simple, but in practice only an ecosystem
like rust who makes heavy use of cyclic dependency relations intermixed
with versioned provides actually triggers this as seen by the buggy code
being in use for four months in Debian and Ubuntu development releases.
(easier to trigger if most packages are marked manual installed)

Note that the testcase is successful already due to the earlier changes
as we exit the recursion eventually and all packages are marked as they
need to be already, but this fix does work standalone as well.

Closes: #992993
</content>
</entry>
<entry>
<title>Don't venture too deeply in AutoRemovers MarkPackage</title>
<updated>2021-08-28T20:21:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-08-28T17:49:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e4701219cf821d24f7f48ed6e4d8123c11d47c8b'/>
<id>urn:sha1:e4701219cf821d24f7f48ed6e4d8123c11d47c8b</id>
<content type='text'>
MarkInstall has the same depth limit, so lets use this arbitrary limit
to avoid trying to hard as that usually means we will never stop – at
least not until we crash, which is not a very good error case.
</content>
</entry>
<entry>
<title>Move hidden MarkPackage to a static function</title>
<updated>2021-08-28T20:21:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-08-28T17:22:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d7e9f0779043814d6e7a4141170fa7f18cd90803'/>
<id>urn:sha1:d7e9f0779043814d6e7a4141170fa7f18cd90803</id>
<content type='text'>
We can't have external users as its marked hidden and as we don't even
have users outside of pkgDepCache itself we can remove the function
completely from the public eye. That adds many new parameters, but it
also allows to add a few more like avoiding constantly checking the
debug config value.

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Simplify selection of highest source version providers</title>
<updated>2021-08-28T20:21:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-08-28T11:24:06Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b104891d015d0b8e152d8ac723027f824077948a'/>
<id>urn:sha1:b104891d015d0b8e152d8ac723027f824077948a</id>
<content type='text'>
The old code is a bit longer and does a sort (N*log(N)) + find (at most N)
It is replaced by max_element (N) + remove_if (N). The practical
difference is minimal as the N we operate on is rather small, but the
replacement is hopefully easier to understand at a glance as well.

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Store versioned kernel package detectors in d-pointer</title>
<updated>2021-04-26T11:00:24Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-03-18T18:08:48Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6f01e7cc0c6f231711b3b81a81beb3775f0a855a'/>
<id>urn:sha1:6f01e7cc0c6f231711b3b81a81beb3775f0a855a</id>
<content type='text'>
They are kinda costly, so it makes more sense to keep them around in
private storage rather than generate them all the time in the
MarkPackage method. We do keep them lazy through as we have that
implemented already.
</content>
</entry>
</feed>
