Hi, I think there are some oversights and misunderstandings of the Debian procedure by the maintainer. Instead of arguing point-by-point, let me point out few helpful facts. We all are human and makes oversights. So please do not feel bad.
Lintian is there to help maintainers to package better quality packages compliant to the Policy. If there is any discrepancy between them, we need to file a bug report on Lintian to fix Lintian with better heuristics. So you can not reject the Policy based request using Lintian as an excuse. But does Lintian really suggest to use "recommends" but rejects using "suggests"? I do not find it so. This is Lintian output: --- W: cvs source: debian-rules-missing-recommended-target build-arch W: cvs source: debian-rules-missing-recommended-target build-indep I: cvs: arch-dep-package-has-big-usr-share 3342kB 81% E: cvs: missing-dep-for-interpreter mksh => mksh (usr/bin/cvs-switchroot) O: cvs: csh-considered-harmful usr/share/cvs/contrib/sccs2rcs O: cvs: missing-dep-for-interpreter csh => tcsh | csh | c-shell (usr/share/cvs/contrib/sccs2rcs) --- If you use -i option or parse this log with lintian-info, you get full explanation for "E: cvs:..." as: --- E: cvs: missing-dep-for-interpreter mksh => mksh (usr/bin/cvs-switchroot) N: N: You used an interpreter for a script that is not in an essential N: package. In most cases, you will need to add a Dependency on the N: package that contains the interpreter. If the dependency is already N: present, please file a bug against Lintian with the details of your N: package so that its database can be updated. N: N: In some cases a weaker relationship, such as Suggests or Recommends, N: will be more appropriate. N: N: Severity: important, Certainty: possible N: --- At least with the latest Lintian, the resolution proposed is very clear and right. You can use either Suggests or Recommends. (You may have seen a different message with the version you used.) As you know, putting package in Recommends set them autoinstall for most reasonable package managers while putting it in Suggests does not. This is where we felt unexpected action for the very obscurely documented command. I made a test build while putting mksh in Suggests and confirmed that Lintian was happy with it (no ERROR like above). As for manpage, if you read its file content, it contains: --- .\" This is the man page for CVS. It is auto-generated from the .\" cvs.man.header, cvs.texinfo, & cvs.man.footer files. Please make changes .\" there. A full copyright & license notice may also be found in cvs.texinfo. --- So autogenerated is no excuse. You can fix "doc/cvs.man.footer" to get your cvs-switchroot listed there :-) As for /usr/bin/cvsbug, I have no idea it is used or not. It seems more of question for you if you want to get bug report via this as the way it is written. At least for the Debian package, it seems to be better to disable this while providing proper bug script so Debian BTS get good information. You can find its documentation in /usr/share/doc/reportbug/README.developers.gz (You can use this script to ask user not to file wishlist request for pserver etc. to cut down on useless bug report.) One packaging FEATURE I did not agree was removal of old Debian changelog entries. If you have included any of the patches generated in Debian as you mention, removing their contribution record seems not right for me. What is wrong to keep them so people know the history before your complete repackage. Please reconsider. As for "epoch", the Policy "5.6.12 Version" states: | It is provided to allow mistakes in the version numbers of older | versions of a package, and also a package's previous version numbering | schemes, to be left behind. Thus, this epoch should not be used lightly. The rationale to use new epoch should not be the local unpublished packaging history. Such things should be fixed before uploading package to the Debian. It is interesting to see that the old orig.tar.gz contained tar.bz2 inside. If you kept old changelog, it is clear this was done in 2006 by Steve McIntyre. Support for bz2 was added to dpkg 1.10.24 in 2004 and not so popular yet to use this functionality (maybe for backport concern etc.) in 2006. I did not experiment or tested, but most likely, since dpkg-scanpackage put priority to package.bz2 over package.gz, you could have used and uploaded real 1.12.13.orig.tar.bz2 while building package with dpkg-buildpackage option -sa. Then archive size bloat did not happen. So you may have have a clean package upload without non-standard "+real" (Just a thought... I know it is too late now). Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
