<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/deb/deblistparser.cc, branch 2.9.1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.9.1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.9.1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2024-03-07T15:35:17Z</updated>
<entry>
<title>Parse unsupported != relation in dependencies</title>
<updated>2024-03-07T15:35:17Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2024-01-23T13:45:46Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=3d1614b0a6c9c185ed1b2834e338f14d4de5b124'/>
<id>urn:sha1:3d1614b0a6c9c185ed1b2834e338f14d4de5b124</id>
<content type='text'>
libapt has a NotEquals relation for version constraints in
dependencies, which is used internally e.g. in the MultiArch
implementation, but this relation is not supported by Debian
policy and as such can not be used in packages.

Our parser here is extremely accepting, even unknown relations are
parsed as Equals relation – but the version that must match will be a
rather strange one…

For our own testcases and e.g. on the command line with 'satisfy' it
can make sense to have != available… and what strange things apt does
parsing unsupported relations is not really much of a concern. Real
packages will not have such relations anyhow as we are (mostly) just
a consumer, not a producer of packages and index files.
</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>Stop calculating Description-md5 if missing</title>
<updated>2023-10-04T12:17:16Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-10-04T12:17:16Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b24d6a1f3aff12f32f6a7024aac6961089f99719'/>
<id>urn:sha1:b24d6a1f3aff12f32f6a7024aac6961089f99719</id>
<content type='text'>
This avoids the rabbit hole of md5 on FIPS systems, and repositories
have moved to including the value as well.

Also stop validating the field, this can be an arbitrary string
as far as we are concerned.
</content>
</entry>
<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>Drop support for long obsoleted Suggests alias: Optional</title>
<updated>2022-04-01T12:16:15Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-03-28T13:25:36Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7b8da771e2061462b9196f38366c34e4f919d0df'/>
<id>urn:sha1:7b8da771e2061462b9196f38366c34e4f919d0df</id>
<content type='text'>
dpkg-dev stopped recognizing it in 2007 (1.14.7) while building packages.
The rename itself happened in 1995 (0.93.72).
</content>
</entry>
<entry>
<title>Barbarian M-A:allowed don't satisfy :any deps of other archs</title>
<updated>2021-09-04T13:35:15Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-09-04T00:22:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=79a675ddf3320bf640d130e592c86fefd1a460e1'/>
<id>urn:sha1:79a675ddf3320bf640d130e592c86fefd1a460e1</id>
<content type='text'>
What does a M-A:allowed package from non-native/non-foreign architecture
provide? If we look at M-A:foreign, such a package satisfies
dependencies within its own architecture, but not in other
architectures, so the same should apply to :any dependencies on
M-A:allowed packages, but we have a problem: While unqualified package
names are architecture-specific, the virtual package name qualified with
:any is not (see 3addaba1ff).

We could of course make it architecture-specific now, but that would
introduce many virtual packages for this relatively minor usecase and
would reintroduce a need for special display handling.

So, we pull a trick here: Barbarian M-A:allowed packages do not provide
the architecture-independent :any package anymore, but only a specific
one and every :any dependency from a barbarian package is rewritten to
an or-group of the specific and the independent :any package.

References: 3addaba1ff
</content>
</entry>
<entry>
<title>Store size from volatile sources for already installed versions</title>
<updated>2021-06-10T10:58:24Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-06-10T10:58:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=7adecd8b2543fc8ee5288b91525a366cf9525cb8'/>
<id>urn:sha1:7adecd8b2543fc8ee5288b91525a366cf9525cb8</id>
<content type='text'>
Volatile sources are parsed after the status file, so if we have a
version already installed the size information is not stored, so that
a reinstall of said version is refused claiming a broken repository.

References: 1412cf51403286e9c040f9f86fd4d8306e62aff2
</content>
</entry>
<entry>
<title>Include all translations when building the cache</title>
<updated>2021-01-27T11:48:58Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-01-27T11:31:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ccd952cc8793bc6b866f92912ef0bb51c42eb540'/>
<id>urn:sha1:ccd952cc8793bc6b866f92912ef0bb51c42eb540</id>
<content type='text'>
We do download all translations we ever downloaded, but we don't add all
of those to the cache, meaning that if we run update with LANG=C, it
might still download your de_DE translation, but it won't insert it into
the cache, causing your de_DE user to not get translated messages.

LP: #1907850
</content>
</entry>
<entry>
<title>Add support for Phased-Update-Percentage</title>
<updated>2021-01-08T13:48:47Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2020-08-10T18:16:11Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=c5bc86d45e003905ef411146e66b414d26fb1ff8'/>
<id>urn:sha1:c5bc86d45e003905ef411146e66b414d26fb1ff8</id>
<content type='text'>
This adds support for Phased-Update-Percentage by pinning
upgrades that are not to be installed down to 1.

The output of policy has been changed to add the level of
phasing, and documentation has been improved to document
how phased updates work.

The patch detects if it is running in a chroot, and if so, always
includes phased updates, restoring classic apt behavior to avoid
behavioral changes on buildd chroots.

Various options are added to control this all:

* APT::Get::{Always,Never}-Include-Phased-Updates and their legacy
  update-manager equivalents to always or never include phased updates
* APT::Machine-ID can be set to a UUID string to have all machines in a
  fleet phase the same
* Dir::Etc::Machine-ID is weird in that it's default is sort of like
  ../machine-id, but not really, as ../machine-id would look up
  $PWD/../machine-id and not relative to Dir::Etc; but it allows you to
  override the path to machine-id (as opposed to the value)
* Dir::Bin::ischroot is the path to the ischroot(1) binary which is used
  to detect whether we are running in a chroot.
</content>
</entry>
<entry>
<title>Determine autoremovable kernels at run-time</title>
<updated>2021-01-04T09:46:48Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2020-12-17T12:24:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=04085f46dea9a95dd86123ac00187a63cc4ba2c0'/>
<id>urn:sha1:04085f46dea9a95dd86123ac00187a63cc4ba2c0</id>
<content type='text'>
Our kernel autoremoval helper script protects the currently booted
kernel, but it only runs whenever we install or remove a kernel,
causing it to protect the kernel that was booted at that point in time,
which is not necessarily the same kernel as the one that is running
right now.

Reimplement the logic in C++ such that we can calculate it at run-time:
Provide a function to produce a regular expression that matches all
kernels that need protecting, and by changing the default root set
function in the DepCache to make use of that expression.

Note that the code groups the kernels by versions as before, and then
marks all kernel packages with the same version.

This optimized version inserts a virtual package $kernel into the cache
when building it to avoid having to iterate over all packages in the
cache to find the installed ones, significantly improving performance at
a minor cost when building the cache.

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