2014-01-31 Daniel Hartwig <mand...@gmail.com>: > On 31 January 2014 20:32, Manuel A. Fernandez Montecelo > <manuel.montez...@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.montez...@gmail.com> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
