[Aptitude-devel] Bug#357542: aptitude: changelog display does not work on recent uploads

Daniel Hartwig mandyke at gmail.com
Mon Feb 3 17:46:17 UTC 2014

On 1 February 2014 23:25, Manuel A. Fernandez Montecelo
<manuel.montezelo at gmail.com> wrote:
> 2014-01-31 Daniel Hartwig <mandyke at gmail.com>:
>> On 31 January 2014 20:32, Manuel A. Fernandez Montecelo
>> <manuel.montezelo at gmail.com> wrote:
>>> Control: owner -1 !
>>> This can probably be fixed now by downloading the files from the
>>> target distribution, when the first attempt to get by package name and
>>> version fails, e.g.:
>>> experimental_changelog
>>> unstable_changelog
>> Those files are updated at the same time as NAME_VERSION_changelog, so
>> if this is not available then DIST_changelog will be for an older
>> version and not contain the recent changes.
> I think that it would happen the contrary, the DIST_changelog would
> always be same or newer, and if anything NAME_VERSION+1_changelog
> replaced the version that aptitude asks about. Because this
> "metadata" central place would be always more up to date than the
> mirror (or the last "aptitude update").
> Even if giving a newer version than expected, I think that it's a
> nicer fall-back than having a "404" because it cannot find the file
> for the exact version, and by the most recent version of the changelog
> one can see (if one cares about looking at the version line) that the
> version is not available.

Sure, if a newer version is fetched that is certainly ok.

> In general, DIST_changelog should always exist, unless the package is
> removed or renamed, that's why I think that it would be a good
> fallback.

>>> http://metadata.ftp-master.debian.org/changelogs/main/m/mono/
>> Does this service update more immediately than packages.d.o?  If so,
>> then it is quite possibly this is not an issue any more.
> I expect that, being under control of FTP masters (gatekeepers of
> packages in the archive), is more up to date than packages.d.o in the
> past, even if only for propagation delays.

Right.  The metadata service is updated as part of the dak runs, i.e.
at the same time or immediately after the rest of the archive is
updated.  A quick look at timestamps of some changelogs shows delays
in the order of tens of minutes as opposed to the hours or more that
packages.d.o used to take.

> But packages.d.o now is a redirection to metadata.  The only real
> difference now is probably that aptitude would be accessing with an
> extra redirection that could cause problem if the redirection goes
> away (the lack of which caused the original bug report) or the server
> is down.
> Sysadmins also announced that metadata is serverd by a CDN now, so
> perhaps is a tad more efficient.
>> If the delay is still noticeable (I have not noticed since the
>> switch), then DIST_changelog may be a reasonable fallback.  I presume
>> the user will want some notice that they have not received the most
>> recent changelog/changelog for the version they requested.
> I think that this would almost always only happen in testing or
> unstable (not stable), I don't think that this realistically can
> affect anybody in stable, or that nobody will cares enough (if
> anything, the newer version will contain important fixes).
> Personally, using mostly unstable (where this can happen more often),
> I am not overly worried about the versions of packages that I am about
> to install which maybe are not in the mirrors, because the situation
> in unstable can change at any moment (it's perfectly possible to have
> more than 1 version uploaded per day), and in testing at least once
> per day.
> In any case, perhaps is an issue for some users, and we can add the
> suggested warning.  Is printing a warning message along with the
> example below enough (which cannot be seen until after the pager
> quits), or should it require to press a key to make sure that the user
> notices before seeing the changelog in the pager?
>   Get: Changelog of libdrm
>   Get: Changelog of libdrm2
>   Warning: Changelog of libdrm2 is for latest version in unstable
> (3.2-1 not found)

Sure, something like that.

Perhaps wait to see if it is still a problem after the next release
(with changelogs fetched from the new service).


More information about the Aptitude-devel mailing list