apt/apt-pkg/pkgcachegen.cc, branch 2.9.27Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.9.272025-01-30T23:10:02ZRecord all available sources for descriptions2025-01-30T23:10:02ZDavid Kalnischkiesdavid@kalnischkies.de2025-01-30T23:10:02Zurn:sha1:593cf30cee476bdae21f7e99f67d2572b7381e90
Avoiding duplications is one thing, but it could also be handy to know
all sources for a description so that you can e.g. avoid opening another
file or similar such if its also present in one you already have open.
Given how the structures were set up this was probably intended all
along and either worked at some point or was abandoned for the
duplicates that we started culling heavily with the introduction of
MultiArch as at that point they blew up the cache and needed to be dealt
with.
Do not create descriptions structs for each architecture2025-01-30T21:45:40ZDavid Kalnischkiesdavid@kalnischkies.de2025-01-30T21:45:40Zurn:sha1:d0c2cc03d75fa66986a9aadf8b1361426e9ceb4d
The architectures are supposed to share the descriptions as they are
(very usually) the same, but the code was happily creating structs
for every architecture of a package which is especially pointless as
for e.g. Debian those will be the short description likely superseded
in output and all uses by the 'en' "translation".
Drop unused version stanza size info from binary cache2025-01-30T19:10:50ZDavid Kalnischkiesdavid@kalnischkies.de2025-01-30T18:03:26Zurn:sha1:1bc8dab8df60c5da7cc817bec5f53e60f7eb9817
Same reason as with the description size before, but this one had
actually one extremely dated user in src:apt left with dumpavail,
which is changed to an implementation that is (in comparison) a bit
slower, but should be good enough for a command that is ideally not
used anymore (even if codesearch suggests otherwise).
After all, what makes this a bit slower is not that we don't know the
size, but that this one does additional work preparing for accessing
the fields which we don't do. In exchange pkgTagFile has a better
implementation for "Jitter" than the old code that we would "just"
need to copy here if speed were really an issue.
Drop unused description size info from binary cache2025-01-30T16:39:40ZDavid Kalnischkiesdavid@kalnischkies.de2025-01-30T16:39:40Zurn:sha1:1bc221a9dd22baa6e2e516d45dc858774cafddd0
Nothing in src:apt uses this information and that isn't all to
surprising as it is usually not that interesting to know how big
a specific stanza of a description is as the max size is available
and you are usually working with more than one description.
So this information just takes up space in our binary cache…
64 bits per structure which can quickly add up to whole MBs
depending on how many (and which) sources you have enabled.
std::string_view const & -> std::string_view2024-11-14T17:41:26Zнабnabijaczleweli@nabijaczleweli.xyz2024-11-14T17:37:57Zurn:sha1:323fcee3730fc8e3edd555f458bf260382f6d3ef
Fixes: 2c03eed649068c8838d971ceeb1a09603dcc8e9c
apt-pkg/pkgcachegen.cc, apt-pkg/pkgcachegen.h: APT::StringView -> std::string_view2024-11-12T19:36:20Zнабnabijaczleweli@nabijaczleweli.xyz2024-11-12T16:59:23Zurn:sha1:e900ad1a727912b340aa43417bff895294854d3bapt-pkg/edsp/edsplistparser.cc: APT::StringView -> std::string_view2024-11-12T19:36:16Zнабnabijaczleweli@nabijaczleweli.xyz2024-11-12T16:59:21Zurn:sha1:982998a061461a503352d85b1d0a76a99c8480cdpkgcachegen: Do not try to chmod or write to /dev/null2024-05-22T20:48:04ZJulian Andres Klodejulian.klode@canonical.com2024-05-22T20:46:31Zurn:sha1:140d36fd16a3d4f1fce0c54474b946d0577f1fde
When -o Dir::Cache::pkgcache or -o Dir::Cache is set to /dev/null
we accidentally changed its mode to 0666; which is certainly not
intended. Avoid this issue by exiting the function early if the
file specified is /dev/null.
Modernize standard library includes2024-02-20T12:49:04ZJulian Andres Klodejulian.klode@canonical.com2024-02-20T12:43:08Zurn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49
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.
pkgcachegen: Use placement new to construct header2024-01-12T12:49:24ZJulian Andres Klodejulian.klode@canonical.com2024-01-12T12:47:52Zurn:sha1:0ee745995b1f45ed321b0c20b151ec8e76e4344f
Avoid copying the header from a stack allocated object as this
will copy uninitialized padding bytes into the cache, triggering
valgrind errors which people then use as a strawman for unrelated
errors on armhf.
In an optimal world we should annotate the allocator however such
that valgrind actually does treat those bytes as uninitialized and
then supress warnings in the harmless places, such that when you
then go and try to access it in a place that matters, you do get
an error for uninitialized memory.
Currently any access within the pool will be considered initialized
which is clearly suboptimal. But this is very much a TBD topic and
involves annotating the allocator everywhere.