Bug#1040299: apt changelog should display local changelogs if fetching fails

[Fabian Grünbichler]

Package: apt
Version: 2.6.1
Severity: minor

Dear Maintainer,

with the recent change of long changelogs being truncated automatically, and
the full version of such truncated changelogs always being fetched by
`apt[-get] changelog`, there is no way anymore to use `apt changelog` to just
display "the changelog", if either

- the repository metadata doesn't contain a `Changelogs` reference (many 3rd
party repositories, but also stable-security and stable-updates!)
- the "online" changelog does not exist (yet)

this is the case for security updates as well, e.g. today's ghostscript update
for bookworm (10.0.0-dfsg11+deb12u1):
- before the update, it fails because the changelog for that version is not
found on metadata.ftp-masters.debian.org (ghostscript is also shipped by the
"main" repository that has metadata.f-m.d.o as Changelogs host)
- after the update, it still fails for the same reason, even though at least
the truncated changelog is available by virtue of the package being
installed..

it would be nice if we could get back the old behaviour of "if fetching fails,
display local changelog contents" (possibly with a hint/warning about that fact).

it also seems to me like it is possible to confuse apt about where to fetch
changelogs from, as per the above example (security upgrade fetches changelog
from regular repo) - but since that requires control of the Release file, it's
probably not much of an issue in practice.

-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apt depends on:
ii adduser 3.134
ii debian-archive-keyring 2023.3
ii gpgv 2.2.40-1.1
ii libapt-pkg6.0 2.6.1
ii libc6 2.36-9
ii libgcc-s1 12.2.0-14
ii libgnutls30 3.7.9-2
ii libseccomp2 2.5.4-1+b3
ii libstdc++6 12.2.0-14
ii libsystemd0 252.6-1

Versions of packages apt recommends:
ii ca-certificates 20230311

Versions of packages apt suggests:
pn apt-doc <none>
ii aptitude 0.8.13-5
ii dpkg-dev 1.21.22
ii gnupg 2.2.40-1.1
pn powermgmt-base <none>

-- no debconf information

[Julian Andres Klode]

control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 stable-{security,updates} miss Changelogs field in Release file

On Tue, Jul 04, 2023 at 09:51:47AM +0200, Fabian Grünbichler wrote:
> Package: apt
> Version: 2.6.1
> Severity: minor
>
> Dear Maintainer,
>
> with the recent change of long changelogs being truncated automatically, and
> the full version of such truncated changelogs always being fetched by
> `apt[-get] changelog`, there is no way anymore to use `apt changelog` to just
> display "the changelog", if either
>
> - the repository metadata doesn't contain a `Changelogs` reference (many 3rd
> party repositories, but also stable-security and stable-updates!)

Cloning the bug to ftp.debian.org accordingly

> - the "online" changelog does not exist (yet)
>
> this is the case for security updates as well, e.g. today's ghostscript update
> for bookworm (10.0.0-dfsg11+deb12u1):
> - before the update, it fails because the changelog for that version is not
> found on metadata.ftp-masters.debian.org (ghostscript is also shipped by the
> "main" repository that has metadata.f-m.d.o as Changelogs host)
> - after the update, it still fails for the same reason, even though at least
> the truncated changelog is available by virtue of the package being
> installed..
>
> it would be nice if we could get back the old behaviour of "if fetching fails,
> display local changelog contents" (possibly with a hint/warning about that fact).

We never had that behavior, it would be nice and it would have been my
preferred approach, but it needs a lot of work to add fallback to the
downloading item, we ran out of time for the release for this or the
other more flexible approach with options to control the behaviour.

>
> it also seems to me like it is possible to confuse apt about where to fetch
> changelogs from, as per the above example (security upgrade fetches changelog
> from regular repo) - but since that requires control of the Release file, it's
> probably not much of an issue in practice.

That is not possible, no. APT is fetching the changelogs as instructed
by the repository metadata, and the defaults, and Origin: Debian has

Acquire::Changelogs::URI::Origin::Debian
"https://metadata.ftp-master.debian.org/changelogs/@CHANGEPATH@_changelog";

I would expect changelogs for -updates and -security to pop up there,
and I do consider it a bug in dak or whatever if a package is published
without a corresponding changelog in place tbh.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en