Hi Sven, thank you very much for your thoughts!
Also hi to Alberto Gonzalez Iniesta and Stephen Gran. I added you two to CC for you maintain openvpn and freeradius. The openvpn-auth-radius package is to combine these packages. Sven was uncomfortable with it being maintained by a company and suggested a team (see "team stuff" paragraph). On Mon, Jan 03, 2011 at 02:06:34PM +0100, Sven Hoexter wrote: > * The main technical thing is that I'm not able to double-build the package > in the same location. It seems that the clean target in the makefile only > removes the build object files with a .o suffix. The 'main' file doesn't > have one so it's left behind. Something that should be fixed upstream. > Workaround is to delete it in your clean target in debian/rules. I agree that this should be fixed upstream, however I cannot reproduce the issue. The debian/clean file is read by dh_clean which is called by ./debian/rules clean and will remove the main file on clean. I tried to reproduce on both sid amd64 and lenny i386 and both remove the file for me. [begin team stuff] > * I'm not comfortable with the maintainer address set to a company. I've not > yet formed a final opinion on that topic because technically that's just like > any team maintained address but having explicitly a company as the maintainer > is something new (at least for me). Plus I, as the sponsor, am not part of > that team so it's not like sponsoring a team upload but more like sponsoring > an individual maintainer upload. I'm not sure how other people in the project > feel about it. > > My main concern as a sponsor in that regard is that you often try to create > some kind of trust relationship to the person maintaining that package but > if you leave the company for whatever reason the people maintaining the > package > can change and you can go back to the start. Though if you leave and > subsequently orphan the package we'll technically end up in the same > situation. > > Another point might be that a company as a maintainer might suggest that this > company has a special role within Debian, donno how innocent users might > react to this. Could be avoided if you'd name it 'Cygnusnetwork Debian Team' > or something like that. The concerns are understandable, especially your concern about trust. The company was chosen as maintainer for the actual maintainer probably will change at some point in time, so picking the company will provide a more stable contact and long term user. I'd further your suggestion to use a team that is not strictly related to the company. This would make the packaging more open to other contributors. However creating a team of one and a half (mainly reporting problems to me) members does not seem useful to me. It should be no problem to create a mailinglist if that helps. Using a mailinglist provided by debian is no problem either. Also joining an existing team is possible. Can anyone suggest one to join? Which of the mentioned options would you prefer and why? [end team stuff] > * There is a spurious file debian/clean in the package. Looks like a leftover > from a failed build or something like that. Do you use pbuilder/sbuild or > something similar? Did you remove the file? This would explain why clean failed for you. I mostly build normal systems, but also tested building with pbuilder. > * I would prefer an initial -1 upload. Though that's a matter of personal > taste as far as I remember the discussions on that topic. Different sponsors have different thoughts on this and I picked by incidence the one published by Neil Williams. It also aids in deployment internally. If you require a -1, tell me and I upload. > * I don't agree with your backport argument against the dh override_ syntax. > backports.debian.org has a dh backport and you only need it to build the > source package. Oh and squeeze is not that far away from a release though I > know about people still runing etch (and I always cry when I hear those > stories). Anyway that's not a show-stopper. You precisely hit the point: The package builds on etch with backported debhelper. (Now I can hear you cry. ;-) I don't recommend doing so. I will update the package to the override_ syntax once I am sure that I will not have to support etch. Helmut -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110104121352.ga4...@buero.cygnusnet.de
