Re: Is there a generic canonical way for a package script to check network connectivity?
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.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: