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

[Manuel A. Fernandez Montecelo]

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.

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.

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)


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>