I would be delighted to punt the network changelog fetching functionality from apt-listchanges entirely, but I want to make 100% certain there's no context in which it's needed before I do that.
Here's the NEWS entry from when this functionality was added in 2017:
apt-listchanges (3.14) unstable; urgency=low
When displaying changelogs during upgrades is enabled, but no changelog
file is provided by any of binary packages being processed together, then
apt-listchanges will call `apt-get changelog' command to retrieve changes
over network. (Similar functionality has existed in Ubuntu for ages, and
was incorporated into Debian a few versions ago.)
If for some reason, like limited network connectivity, this behavior
is undesirable, it can be now disabled with the new `--no-network' option
that can be also set using debconf interface:
dpkg-reconfigure apt-listchanges
Additionally the debconf interface was improved to manage a few older
configuration options, for example `--email-format'.
-- Robert Luberda <robert@debian.org> Sun, 09 Jul 2017 09:55:48 +0200
So, the question is: is there something Russ said below that's true now but wasn't true back in 2017, such that this functionality was necessary then but isn't now; or were we mistaken back in 2017 when we thought this functionality was necessary; or is there something Russ said below that doesn't hold up such that actually we still need this?
What about providers of Debian packages and apt repositories other than Debian itself? Don't we need to worry that there may be packages and repositories out there that provide network changelogs but don't include them in their packages? I don't think we want to simply not display changelogs for such packages, do we?
jik
Jonathan Kamens <jik@kamens.us> writes:Regarding what I'm trying to accomplish, as part of the revamp of apt-listchanges I need to rebuild the database that apt-listchanges uses to determine which changelog and NEWS entries it has already shown to the user. This can mostly be done from files installed on the local machine, but not for packages which don't ship a changelog.Debian file and instead expect the user to fetch it over the network with "apt changelog".Based on some other private conversation, I think there may be an underlying misunderstanding here, which is quite inobvious if you're just looking at Debian packages without having read all the previous discussions that got us here. Either that, or I have some incorrect assumptions, and someone should correct me. :) I believe that the following statements are true: Every Debian package either ships changelog.Debian or symlinks its doc directory to another package that ships changelog.Debian. In the latter case, that is a declaration that the package has no unique changelog entries and its changelog is always and exactly the changelog of the other package. (This is used to deduplicate files among packages that are always built together from the same source and are usually installed together.) So there are no packages in Debian that expect the user to fetch the changelog over the network; the changelog is always guaranteed to be part of the content installed on disk. It can just be indirected through another package (if the packages follow some strict limitations). What *does* happen is that some packages (well, all packages that have been rebuilt with current debhelper, I think) have *truncated* changelogs, in order to prevent the changelog from wasting a lot of disk space with old entries, and the *full* changelog is only available via the network. But the guarantee for truncated changelogs is that all entries newer than the release date of oldstable are retained, so since Debian doesn't support skip-version upgrades, apt-listchanges should never need the content that is dropped by truncation. In other words, the intent is to guarantee that all the information that apt-listchanges needs is present on disk, but it would have to deal with the /usr/share/doc symlinks.