Thanks to everyone for the useful feedback. Some additional info and
comments:
I'm well aware that this is a hard problem and that just calling nmcli
is not an adequate solution. I was asking whether the problem has
already been solved in a Debian-canonical way, since there are lots of
other problems of this sort which do have such canonical solutions.
Judging from the responses, it appears that the answer to that question
is no.
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". Ideally I would be able to run a script in the background
which gradually fetches these and adds them to apt-listchanges's database.
Ideally I would be able to simply attempt to fetch the each required
changelog over the network and distinguish between "The fetch failed
because there is no network changelog for this package" and "The fetch
failed because it's not accessible over the network right now", but I
can't make that distinction because neither apt nor python3-apt informs
the user about what went wrong in any way that the caller can use reliably.
I've come up with a different workaround for this edge case which will
do the right thing most of the time, but there are still going to be a
few cases where, because I can't populate the database in advance, when
the user goes to update a package they're going to end up getting shown
the entire network changelog rather than just the new entries, because
apt-listchanges can't reliably determine which entries they've already seen.
jik
