Hi, On Fri, Jun 24, 2011 at 04:03:22PM +0000, Thorsten Glaser wrote: > Osamu Aoki dixit: ... > Also here, I said I will do something. Don’t rush me, please.
As a user, non-optimal dependency is quite annoying. Thanks for changing this. I may have responded a bit too strong on some parts of your message. I am happy with what you did. Other suggestion are non-critical. I meant to help you promote your cvs-switchroot to gain more attention without causing negative effects etc. with concrete suggestion. You can pick what you like. > >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 ;-) I usually do not bother for this somewhat obscure part of Debian infrastructure for my package but I have seen others have used for some similar case as yours. It actually took me a while to find this doc which used to be in the bug package. I do not know what you wish to say... but since you asked, I can send an example. What do you think of adding /usr/share/bug/cvs/presubj file with something along --- pserver functionality is disabled intentionally by the maintainer due to its security implication. Even wishlist bug reports are not accepted. --- If you happen to worry library dependency, it may help adding /usr/share/bug/cvs/script file with something along --- #!/bin/sh /usr/bin/ldd /usr/bin/cvs 1>&3 --- You can find many examples on your Debian system under /usr/share/bug/. Please note I am not asking to do these. Just FYI. > >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. This is from your perspective. I see no policy on this matter. I am not in position to request you to change this based on the policy. Please remember SC#4 "Our priorities are our users and free software". At least you created an iffy user. I wonder what happened on all security fixes done between upstream release of 2006 and last Debian package before yours in 2008. This is completly off-topic from the original bug. Let's discuss separately later with cooler head. > >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 Certainly, these are abuse. Sigh... > >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. Good to hear your intent but GNU upstream seems to be very quiet. Let's hope someday, we see cvs 1.12.14 release. (FYI: Your assertion of "bzip2 is a joke" was surprise to me. If you said "lzma", it made sense to me. Anyway, both lzma and xz suffix are still too new if you think of supporting backports in Debian and Ubuntu. But here, I think you are making judgement as the maintainer and I am happy with you holding this position.) > >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 You tried package.gz and it did not work. I am talking package.bz2. Anyway, it is history now. Let's move on. > 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. I agree you as a maintainer is free to make decision on packaging and it stands. I agree you can make unpopular decisions. In such case, proper documentation of decisions are good practice to be in line with SC#4. Please understand that I have reported to the bug report as a user and I have no intent to be a maintainer of this package. Users including myself are allowed to express their findings on non-optimal behavior of the package. Usually, if bug report states an example of workaround, it is easier for the maintainer to put the better resolution. Regards, Osamu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
