Osamu Aoki dixit: >Lintian is there to help maintainers to package better quality packages
I use lintian all the time, thank you very much. I even used linda, back then. >But does Lintian really suggest to use "recommends" but rejects using >"suggests"? I do not find it so. This is Lintian output: […] >At least with the latest Lintian, the resolution proposed is very clear >and right. You can use either Suggests or Recommends. (You may have I said I need to re-check whether Suggests is enough. I never said that lintian doesn’t accept Suggests, I only said that lintian told me to put a dependency on it and I didn’t remember whether Suggests would be enough.See <[email protected]>: | lintian tells me that, if there is a script with #!/bin/mksh as | shebang, I must put that as sort of dependency. I#ll evaluate | whether Suggests is enough (as *buntu demoted it already). >As you know, putting package in Recommends set them autoinstall for most >reasonable package managers while putting it in Suggests does not. This I still think this is a mistake, and I run several hundred systems with 「APT::Install-Recommends "0";」 in apt.conf ☺ but yes, I know about this. I did not tell you off, I just told you I will re-check it when I next have time to work on the cvs package. Your additional input at this time was not required, because I already agreed – se‐ veral times in fact – that something will be changed. >I made a test build while putting mksh in Suggests and confirmed that >Lintian was happy with it (no ERROR like above). Why, thank you for testing this for me ;-) it will become Suggests then. >So autogenerated is no excuse. You can fix "doc/cvs.man.footer" to get >your cvs-switchroot listed there :-) See Message-ID: <[email protected]> | > * add cvs-switchroot listed at the bottom of SEE ALSO in cvs manpage | | Hm. Will have a look at that at least. Also here, I said I will do something. Don’t rush me, please. >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 Hm. You might have a point there. >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.) Good idea! Please send a file ;-) >One packaging FEATURE I did not agree was removal of old Debian >changelog entries. There was never a removal, because these were never part of this cvs packaging. I mentioned I would completely replace the old packaging before I tool over cvs. >As for "epoch", the Policy "5.6.12 Version" states: >| It is provided to allow mistakes in the version numbers of older Yes, there was a mistake along the way, and the epoch was raised from 1 to 2 by me. Blame me for that, but it cannot be undone now. >Thus, this epoch should not be used lightly. *cough* http://debblog.philkern.de/2011/06/about-versions.html >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 bzip2 is a joke, redundant with xz, and re-compressing already-compressed files does not gain us anything. Furthermore, using tarball-in-tarball packaging was deprecared in 2009 or so. I got told off for that myself, and the “new” cvs package provides the source that’s used for compiling on dpkg-source -x, as many people wanted. So I would have needed to change the .orig.tar.gz already, anyway. Besides, the +real will go away with cvs 1.12.14 release. >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. No. That’s what I tried first. Since there was already a .orig file in the archive, the upload got rejected. https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/cvs/debian/changelog.diff?r1=1.14;r2=1.15 https://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/deb/cvs/debian/changelog#rev1.15 While I like cvs being used, and useful feedback, I do not like to be told how to make my package. If you wanted to have changed the cvs package, there were months in which you could have taken it over. Also, when I said I was going to replace the packaging, I included a link, and there still was a large period before. At the current point in time, I am the maintainer of cvs, and my decisions stand. They may not always be popular, but they usually have reasons. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
