[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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.


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

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,

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:


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.


Thomas Goirand (zigo)

Reply to: