Re: [PING] RFR/RFS: openvpn-auth-radius (new package, fixes retitled RFP)
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
Reply to: