<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/pkgcache.cc, branch 2.9.28</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.9.28</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.9.28'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2025-01-30T23:39:50Z</updated>
<entry>
<title>Include Extra in the size counted for Version struct</title>
<updated>2025-01-30T23:39:50Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2025-01-30T23:39:50Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ce3794a7df13f3d7387b4e4520221421ee92127b'/>
<id>urn:sha1:ce3794a7df13f3d7387b4e4520221421ee92127b</id>
<content type='text'>
It is a tiny struct, so the difference in 'stats' is minor even with all
the versions but it is more correct and also helps in case the Extra
struct is changed to predictably trigger a binary cache invalidation.
</content>
</entry>
<entry>
<title>Write Pre-Depends with a dash again in EDSP</title>
<updated>2025-01-17T00:27:48Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2025-01-17T00:01:13Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4454fd246b3b7f605dcd272b2107313ba53688c5'/>
<id>urn:sha1:4454fd246b3b7f605dcd272b2107313ba53688c5</id>
<content type='text'>
For some reason ~ that I don't know and can't come up with on the spot ~
we output the Pre-Depends field as PreDepends in the translated
user-visible output and I accidentally copied that over to the
untranslated variant that replaced the embedded copy (with a dash)
in the EDSP generator.

Code-copies and implementation details littered all over the place are
apparently sometimes a good bug-free thing, too…

Regression-of: 6828ae2c2f9268c8187f0fa91b3c464ed84a8476
Closes: #1093254
</content>
</entry>
<entry>
<title>Drop the remaining usage of APT_ARRAY_SIZE</title>
<updated>2025-01-05T22:16:08Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2024-12-26T20:46:23Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=1e2b5197ee350a36fbad006f198bbf8e9a5c8e53'/>
<id>urn:sha1:1e2b5197ee350a36fbad006f198bbf8e9a5c8e53</id>
<content type='text'>
That macro is not that useful as it might perhaps once was. Lets prepare
dropping it now in favour of more standard ways of working with arrays
now.
</content>
</entry>
<entry>
<title>Add pkgCache::{Priority,DepType}_NoL10n to avoid duplication</title>
<updated>2025-01-05T22:16:08Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2024-12-26T20:43:34Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6828ae2c2f9268c8187f0fa91b3c464ed84a8476'/>
<id>urn:sha1:6828ae2c2f9268c8187f0fa91b3c464ed84a8476</id>
<content type='text'>
We don't have many places, but lets reduce the amount of duplicating
these short strings, so that we may find all the places we have to
change if that ever happens.
</content>
</entry>
<entry>
<title>Modernize standard library includes</title>
<updated>2024-02-20T12:49:04Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2024-02-20T12:43:08Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=40a75722c43ae24cb9a99d6730a3b25b65819c49'/>
<id>urn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49</id>
<content type='text'>
This was automated with sed and git-clang-format, and then I had to
fix up the top of policy.cc by hand as git-clang-format accidentally
indented it by two spaces.
</content>
</entry>
<entry>
<title>Add public phased update API</title>
<updated>2024-02-13T13:27:27Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2024-02-12T13:48:48Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a8352c2859a6f84b36fa5cd0af89231cb656b1ce'/>
<id>urn:sha1:a8352c2859a6f84b36fa5cd0af89231cb656b1ce</id>
<content type='text'>
This moves the functions of the PhasedUpgrader class into
various other classes so they can be publicly exposed.

This introduces three new functions:

pkgDepCache::PhasingApplied() tells you whether phasing should
be applied to the package.

pkgProblemResolver::KeepPhasedUpdates() keeps back updates that
have phasing applied.

pkgCache::VerIterator::IsSecurityUpdate() determines whether this
version contains security fixes.
</content>
</entry>
<entry>
<title>Have Grp.FindPreferredPkg return very foreign pkgs as last resort</title>
<updated>2023-12-04T23:35:04Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2023-12-04T19:49:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0abf584b283e3e0f040b9ec0e7153c6e52291b2a'/>
<id>urn:sha1:0abf584b283e3e0f040b9ec0e7153c6e52291b2a</id>
<content type='text'>
Usually this method will return the package in the most preferred
architecture (e.g. native) as that is usually what the user talks about
and also information wise for our internal usage the most dense.

Early on in parsing Packages files through it can happen that we
encounter stanzas about packages in architectures we are not even
configured to know about – we have to collect them anyhow as we might be
requested to show info about them or they could be in the status file
and we can't ignore stanzas in the status file… trouble is that this
method used to not return anything if only such an architecture was
present if we later discover other architectures which causes Provides
and Conflicts which are added lazily on discovery of an architecture
to not be added correctly.

The result is like in the testcase that apt could be instructed to
install a package without respecting its negative dependencies, which is
bad even if its discovered by dpkg and refused. It does only happen with
unknown architectures through which mostly happens if you are unlucky
(amd64 users tend to be very lucky as that sorts early) and use
flat-style repositories containing multiple architectures.

Reported-By: Tianyu Chen (billchenchina) on IRC
</content>
</entry>
<entry>
<title>Invalidate cached architecture list when building cache</title>
<updated>2021-10-19T16:25:51Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-10-19T16:11:14Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=307912e8d74d9684875a791b0550c10afc14b0b0'/>
<id>urn:sha1:307912e8d74d9684875a791b0550c10afc14b0b0</id>
<content type='text'>
Fix a regression in python-apt where switching the architectures
in the config between cache invocations regressed.

Regression-Of: 8ff4e226af55a9feb168477a2b1a99f9c5152e54
Gbp-Dch: full
</content>
</entry>
<entry>
<title>All pkgCaches are MultiArch caches</title>
<updated>2021-09-04T13:35:15Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-09-04T11:03:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8ff4e226af55a9feb168477a2b1a99f9c5152e54'/>
<id>urn:sha1:8ff4e226af55a9feb168477a2b1a99f9c5152e54</id>
<content type='text'>
Back in 2015 the code inside libapt who was using this field was dropped
as even if we are on a system which is not configured for MultiArch,
there are still edge cases in which the cache can include very foreign
packages, so any assumption you could make thinking only a single
architecture will be in the cache is probably wrong.

Maintaining two different codepaths for Multi- and SingleArch is likely
not very beneficial for code and users alike and is surprisingly hard to
answer correctly and becoming even harder still, so always assuming the
"worst case" seems like the far better option.

References: 6c9937da76b9155d166092b9dda22d06200510c1
</content>
</entry>
<entry>
<title>Free XXH3 state to avoid leak in cache hashing</title>
<updated>2021-02-03T16:36:45Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-02-03T09:55:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=cd1f75854824b3db7ba86039463528f834a0838a'/>
<id>urn:sha1:cd1f75854824b3db7ba86039463528f834a0838a</id>
<content type='text'>
We do this once (usually), so the leak is tremendously big, but it is
detected as a leak by the fuzzer and trips it up.
</content>
</entry>
</feed>
