Control: clone -1 -2 Control: reassign -2 debhelper 13.10 Control: clone -2 -3 Control: retitle -2 debhelper: Also trim (or delete) NEWS.Debian.gz if changelog.Debian.gz is trimmed Control: block -1 by -2 Control: retitle -3 debhelper: Revert change to trim changelog.Debian.gz by default Control: severity -3 wishlist Control: tag -1 + wontfix Hi, gregor herrmann wrote: > > The report does not look right: it seems to me that version 0.1.14 is > > indeed present in the changelog file of my package! > > Well, yes and no. It's in debian/changelog in the source package but > as debhelper has started to trim the changelog in binary packages > (13.10, dh_installchangelogs), it's probbaly not in > /usr/share/doc/<pkg>/changelog.Debian.gz. Urgs. IMHO it is a really bad idea to set this as default as such a change does only make sense for a few packages with really large changelog entries like e.g. the Linux kernel. (So doing this automatically size-based, e.g. if the uncompressed debian/changelog is over 1 MB, the trim it by default to the release-date of oldstable, would be ok IMHO.) At least I regularily read changelog.Debian.gz files (usually by searching in them with "/") and are always very annoyed if I notice that they're truncated like e.g. on Ubuntu. Always to have to check if they are truncated before searching in them and then consult the source package for getting the full changelog is IMHO inacceptable. It is though nice to see a standardized possibility to truncate Debian changelogs in debhelper for those packages which actually need it. But doing this by default is IMHO a horrible idea. > > Please investigate and fix this bug in lintian. I see no possibility how to do that in Lintian except for switching the check from a binary to a source package check. Not sure if this is that easily doable. Additionally it will become more complex as it would have each per-binary-package debian/<package>.NEWS files separately. (It would also invalidate any lintian override about it.) But I actually would prefer to not have to do that at all as IMHO that tag is validly emitted and this is IMHO a newly introduced bug in debhelper. Cloning an according (wishlist) bug report against debhelper > Or maybe dh_installchangelogs should trim NEWS.Debian as well? Definitely (and not just IMHO), this is a bug in debhelper. And debhelper probably should even delete NEWS.Debian.gz completely if there are only ancient entries in there. (Actually with these files trimming by default IMHO even makes sense — but not for changelog.Debian.gz.) Cloning another bug report (same severity as this bug report, i.e. #1021502) against debhelper for not trimming NEWS.Debian.gz as well and blocking this bug report with it. But better just don't enable changelog.Debian.gz trimming by default at all or use the version proposed in MR !79 instead of the one from !80. MR !79 IMHO is much more sensitive than !80. IMHO trimming changelog.Debian.gz should not be enabled without either an explicitly set option (and never by default, except maybe size-based) or at least only with a dh compat level bump (as suggested in !79). The current situation is IMHO a rather bad surprise for many package maintainers as well as many users (as it was back then in Ubuntu as well). Regards, Axel -- ,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Attachment:
signature.asc
Description: PGP signature