Bug#357542: aptitude: changelog display does not work on recent uploads
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
Bug#357542: aptitude: changelog display does not work on recent uploads
Control: tags -1 + moreinfo [Waiting on feedback whether this is still an issue on the new changelog service run by ftp-master.] 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 After more consideration, I am not really fond of this proposal because it disregards the user request. aptitude changelog foo=VER explicit request for specified version aptitude changelog foo implicit request for candidate version Error checking is generally being tightened in aptitude, and that includes cases where the users request can not be fulfilled. Anyway, whether this remains an issue using the new changelog service should be seen first before taking further action. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#357542: aptitude: changelog display does not work on recent uploads
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
Bug#357542: aptitude: changelog display does not work on recent uploads
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 http://metadata.ftp-master.debian.org/changelogs/main/m/mono/ 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
Bug#357542: aptitude: changelog display does not work on recent uploads
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. 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. 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. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
