On 1 February 2014 23:25, Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> wrote: > 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. >
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org