Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/24/2011 04:37 AM, Thomas Goirand wrote:
Since I reviewed once your package, I feel like I have to do it again,
and continue the mentoring process. So let me do again, this time
more deeply.
Thanks Thomas, I appreciate your input.
1/ debian/changelog
please remove all other entries.
Done.
My advice
here: write things in /changelog that are only for upstream code,
and in debian/changelog only things that concerns the packaging
itself and nothing else.
Done.
2/ debian/copyright
I believe format is now proper DEP-5.
I fail to see
how it could be more free than with the Apache 2.0 license! :)
I agree that the Apache 2.0 license is a great license! However, I fail
to see how the spirit of the DFSG -- giving people freedom and choice --
is in any way violated by offering alternate licensing to those for whom
a particular license is unacceptable, for whatever reason. Personally, I
feel that the Apache 2.0 license is perfectly acceptable, but others are
free to disagree, and I don't see an issue with making the software
available to them as well. But I could be wrong here about the DFSG, and
would appreciate clarification if I am.
Meanwhile, I removed the alternate licensing stanza.
3/ debian/patches/debian-changes
overriding the dh rules
targets would be more simple to maintain.
Makes sense. Thanks. Done.
4/ debian/postinst
While it's fine to automatically install a site in sites-available,
and install and activate a .load Apache module, actually activating
the default vhost that you created might not be appropriate,
especially since what you are doing is activating a policy with
<site-control permitted-cross-domain-policies="none" /> in it.
Am I right that basically, it will do the same as if nothing was
done at all, and make it completely restrictive?
The default configuration activates a policy that is slightly more
restrictive than the default policy in Flash.
The benefits are that:
* The configuration is secure by default.
* The default configuration gives the system administrator a working
configuration out-of-the-box. Testing a non-standard protocol can
be difficult, and this eases entry.
The drawbacks are that:
* A VirtualHost is enabled by default. I'm not sure if this is a
comparable situation, but the default Apache2 install configures
and enables a default site.
I think that the drawbacks are mitigated in that:
* The VirtualHost is enabled only for port 843.
Any ideas for a better approach? I think is important to be able to
easily verify a working configuration, before modifying that
configuration. Any thoughts?
5/ Your package doesn't build twice
Fixed. Tested with pbuilder --twice
6/ debian/watch file
Please add a watch file.
Done. Tested with uscan
7/ debian/control
Are you sure that this is accurate:
Maintainer: Debian Packaging Team
<debian-packaging-team@socketpolicyserver.com>
My thought here is that I want this address to be useful for maintaining
the project long-term. The business is responsible for the project, not
me personally, and I thought it best to reflect that in the maintainer
field.
Depends: ${misc:Depends}, ${shlibs:Depends}, apache2 | apache2-mpm,
apache2.2-common
But apache2 depends on apache2.2-common, and so are all
the apache2.2-mpm-* packages that are providing apache2.2-mpm,
so I guess that depending on apache2.2-common is useless here
(if you don't think so, feel free to correct me).
I agree is duplicated and would likewise prefer the simpler form... I
included apache2.2-common per the guidelines on:
http://wiki.debian.org/Apache/PackagingModules
Do you know if would be better to remove the dependency or to defer to
those guidelines?
I think that's it for the moment. Let me know when you've
processed all the above issues, and I'll review your package
once more.
Alright, will upload an updated package as soon as have clarification
about the default configuration. Meanwhile, in case it would be helpful,
I uploaded a package reflecting the changes so far.
Then I'd prefer if another DD that did some apache module
packaging had a last look before I sponsor the package for you
(because I may well have missed something).
Sounds good, extra eyes are always appreciated, especially when dealing
with network services.
Cheers,
Thomas Goirand (zigo)
Reply to: