<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/doc/examples, 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-04-13T18:27:48Z</updated>
<entry>
<title>Show space estimate for /boot, if separate; or estimate initrd for /usr</title>
<updated>2024-04-13T18:27:48Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2024-04-13T18:27:48Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f7e5ed3c8dffcdfc2c55c63f2e3cbcb390bbf013'/>
<id>urn:sha1:f7e5ed3c8dffcdfc2c55c63f2e3cbcb390bbf013</id>
<content type='text'>
Calculate an estimate of 110% of the biggest initrd + system.map
as the additional space a kernel needs in /boot.

If /boot is a different file system than /usr, print the size of
the kernels + the additional space they will need separately;
otherwise include it in our /usr figure.
</content>
</entry>
<entry>
<title>apt: Introduce the new terse apt output format 3.0</title>
<updated>2024-04-12T13:57:36Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2024-04-11T21:04:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=abfae1aec588c1b4ae46f229d8312a3c5e6b8b7a'/>
<id>urn:sha1:abfae1aec588c1b4ae46f229d8312a3c5e6b8b7a</id>
<content type='text'>
The key talking points here are:

1. Instead of long sentences, we use short concise messages,
   e.g. "The following NEW packages will be installed" becomes
   "Installing".

2. Dependencies are only listed once. We removed the
   "The following additional packages will be installed" section
   in favor of splitting up the "Installing" section into
   "Installing" and "Installing dependencies" (like dnf)

3. The order of the output is different:

   1. Packages to be installed manually
   2. Packages to be installed automatically
   4. Weak dependencies of new packages not installed
   3. Packages to be upgraded
   4. Packages to be downgraded
   5. Packages that have been kept back / are on hold
   6. Removals
   7. Essential removals

   i.e. we logically show you the action that is being
   done, followed by lists related to the action.

4. As requested by popey, we have colorful UI, with green for
   packages being installed and red for packages being removed.

Caveats:

- The list of recommends and suggests has not been updated yet,
  it should move to after the packages being installed (as they
  are what triggers them)

This also introduces output format versioning, configured by the
APT::Output-Format option. The default value is 0, except for the
apt(8) binary where it is 30 - which enables the new style.
</content>
</entry>
<entry>
<title>OpProgress: Erase lines when done</title>
<updated>2024-04-12T13:57:05Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2024-04-12T10:00:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8ddfeb2fb65dd45267d8f7abfc540d2b8cb73a5c'/>
<id>urn:sha1:8ddfeb2fb65dd45267d8f7abfc540d2b8cb73a5c</id>
<content type='text'>
It's interesting to the user to see the progress when it happens,
but arguably once it's done it is just visual clutter, so let's
not write newlines, and when we are done, instead of appending
"Done", let's just empty the line.

This requires some effort to keep apt-cdrom happy which just writes
lines to stdout itself. Bad apt-cdrom. Maybe there is a better fix
for it, but this gets us going.
</content>
</entry>
<entry>
<title>Columnar output for package lists similar to 'ls'</title>
<updated>2024-04-12T13:56:56Z</updated>
<author>
<name>Christian Blichmann</name>
<email>mail@blichmann.eu</email>
</author>
<published>2022-02-01T19:59:57Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=690993b1b9b4a932ca5bf5374c59e4cf88f18732'/>
<id>urn:sha1:690993b1b9b4a932ca5bf5374c59e4cf88f18732</id>
<content type='text'>
This change makes it a bit easier to quickly grasp the changes
about to be performed by apt.

It displays package lists in a columnar format by default,
similar to what `ls` produces for files.

A new long option `--no-list-columns` and an associated
`APT::Get::List-Columns` config setting control the behavior.

Usage example, with 60 column wide terminal:

```
$ sudo apt upgrade                                          |
Reading package lists... Done                               |
Building dependency tree... Done                            |
Reading state information... Done                           |
Calculating upgrade... Done                                 |
The following packages were automatically installed and are |
no longer required:                                         |
  libappindicator1 libindicator7                            |
  libdbusmenu-gtk4 linux-image-5.14.0-4-amd64               |
Use 'sudo apt autoremove' to remove them.                   |
The following packages have been kept back:                 |
  criu        linux-headers-amd64 nvidia-settings           |
  libxnvctrl0 nvidia-modprobe     xwayland                  |
0 upgraded, 0 newly installed, 0 to remove and 6 not upgrade|
d.                                                          |
```

The effect becomes more pronounced with more packages (e.g. when
doing a dist-upgrade).
</content>
</entry>
<entry>
<title>Implement gpgv --assert-pubkey-algo=&gt;=rsa2048,ed25519,ed448</title>
<updated>2024-02-28T17:22:01Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2024-02-28T14:14:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=50e3fee26ae843a812b1c9ec8531946931773fd3'/>
<id>urn:sha1:50e3fee26ae843a812b1c9ec8531946931773fd3</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Configure the amount of kernels to keep</title>
<updated>2024-01-24T17:23:33Z</updated>
<author>
<name>Wesley Schwengle</name>
<email>wesleys@opperschaap.net</email>
</author>
<published>2024-01-23T19:41:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a6e30cc02eb24d5b2bbf2cb1b59c48c62d09658f'/>
<id>urn:sha1:a6e30cc02eb24d5b2bbf2cb1b59c48c62d09658f</id>
<content type='text'>
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 &lt;wesleys@opperschaap.net&gt;
</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>update: Add notice about missing Signed-By in deb822 sources</title>
<updated>2023-06-27T17:21:47Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-06-27T17:14:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=aba813975abb880f8b27d659147f7760c02f99e7'/>
<id>urn:sha1:aba813975abb880f8b27d659147f7760c02f99e7</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Seed snapshot servers for well-known hosts</title>
<updated>2023-05-24T09:22:44Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-05-17T15:18:33Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=48cbc5413fb2a0e490c2282b9df65da96ad7a9f2'/>
<id>urn:sha1:48cbc5413fb2a0e490c2282b9df65da96ad7a9f2</id>
<content type='text'>
This will attempt to fallback to a per-server setting if we could
not determine a value from the release file.
</content>
</entry>
<entry>
<title>Initial support for snapshot servers, apt --snapshot option</title>
<updated>2023-05-02T13:23:14Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2023-02-22T13:14:52Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a19f606aad717fe5c9c69237c3af53feb547115e'/>
<id>urn:sha1:a19f606aad717fe5c9c69237c3af53feb547115e</id>
<content type='text'>
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.
</content>
</entry>
</feed>
