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

[Daniel Hartwig]

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.
>

Right.
>
>>> 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).


Regards