apt/doc/examples, branch 2.7.13

Implement gpgv --assert-pubkey-algo=>=rsa2048,ed25519,ed448

2024-02-28T17:22:01Z

The assertion can be overriden using apt::key::assert-pubkey-algo, the default is the most opinionated one. This will inform the user during apt-cdrom add as we do not pass --quiet to user, so adjust test case. Add a simple test case for it to test-method-gpgv. LP: #2055193

Configure the amount of kernels to keep

2024-01-24T17:23:33Z

This commit introduces the following configuration for keeping a configurable amount of kernels: APT::NeverAutoRemove::KernelCount The logic dictates that the running kernel and the latest kernel are not autoremoved. In case the running kernel is the latest kernel, the previous kernel is kept. Any count lower than two is therefore disregarded. This is in line with the previous behavior. The default is therefore similar to: APT::NeverAutoRemove::KernelCount 2; This will be ignored and we will still keep two: APT::NeverAutoRemove::KernelCount 1; This will keep 3 kernels (including the runnig, and most recent) APT::NeverAutoRemove::KernelCount 3; Signed-off-by: Wesley Schwengle

Have Grp.FindPreferredPkg return very foreign pkgs as last resort

2023-12-04T23:35:04Z

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

update: Add notice about missing Signed-By in deb822 sources

2023-06-27T17:21:47Z

We want to gently steer users towards having Signed-By for each source such that we can retire a shared keyring across sources which improves resilience against configuration issues and incompetent malicious actors.

Seed snapshot servers for well-known hosts

2023-05-24T09:22:44Z

This will attempt to fallback to a per-server setting if we could not determine a value from the release file.

Initial support for snapshot servers, apt --snapshot option

2023-05-02T13:23:14Z

Provide snapshot support for offical Debian and Ubuntu archives. There are two ways to enable snapshots for sources: 1. Add Snapshot: yes to your sources file ([snapshot=yes]). This will allow you to specify a snapshot to use when updating or installing using the --snapshot,-S option. 2. Add Snapshot: ID to your sources files to request a specific snapshot for this source. Snapshots are discovered using Label and Origin fields in the Release file of the main source, hence you need to have updated the source at least once before you can use snapshots. The Release file may also declare a snapshots server to use, similar to Changelogs, it can contain a Snapshots field with the values: 1. `Snapshots: https://example.com/@SNAPSHOTID@` where `@SNAPSHOTID@` is a placeholder that is replaced with the requested snapshot id 2. `Snapshots: no` to disable snapshot support for this source. Requesting snapshots for this source will result in a failure to load the source. The implementation adds a SHADOWED option to deb source entries, and marks the main entry as SHADOWED when a snapshot has been requested, which will cause it to be updated, but not included in the generated cache. The concern here was that we need to keep generating the shadowed entries because the cleanup in `apt update` deletes any files not queued for download, so we gotta keep downloading the main source. This design is not entirely optimal, but avoids the pitfalls of having to reimplement list cleanup. Gaps: - Ubuntu Pro repositories and PPAs are not yet supported.

Add apt install,upgrade,... -U,--update options

2023-05-02T13:16:54Z

This runs update before opening the cache and sources.list for installing/upgrading.

Suggest using non-free-firmware in update for Debian

2023-02-04T16:56:41Z

In an ideal world everyone would read release notes, but if the last sources.list change is any indication a lot of people wont. This is even more a problem in so far as apt isn't producing errors for invalid repositories, but instead carries on as normal even through it will not be able to install upgrades for the moved packages. This commit implements two scenarios and prints a notice in those cases pointing to the release notes: a) User has 'non-free' but not 'non-free-firmware' b) User has a firmware package which isn't available from anywhere Both only happen if we are talking about a repository which identifies itself as one of Debian and is for a release codenamed bookworm (or sid). Note that as (usually) apt/oldstable is used to upgrade to the new stable release these suggestions only show for users after they have upgraded to bookworm on apt command line usage after that.

Add non-free-firmware component in documentation

2023-01-29T23:55:30Z

This changes a lot of lines technically, but its easy enough to unfuzzy the translations as most of the mentions are examples to be copied literally in translations (sadly po4a isn't clever enough for this).

Add flag to disable upgrade by source and test case

2022-07-24T13:44:13Z