Re: Bug#448532: RFS: phpmyvisites -- free web analytics
Hi Vincent,
Thanks a lot for your feedback. A first round of answers.
Vincent Bernat <bernat@debian.org> (2008-05-21 22:03:52) :
> OoO En cette nuit nuageuse du jeudi 15 mai 2008, vers 01:02, Frederic
> Lehobey <Frederic@Lehobey.net> disait:
> php4 will not be part of lenny, therefore, you can remove php4
> dependencies.
I know this. I left them in the purpose of building backports, but I
can remove them and add them only in the backport. I will remove them
then.
> Moreover, php5 depends on libapache2-mod-php5. You can
> drop "Suggests" too.
Ok. Thanks.
> I don't know if the content of artichow/php4 could
> be dropped too.
Probably, yes.
> You short description is very short. You may want to complete it a
> bit. You should add a blank line in the long description.
Ok. Will fix these.
> About debian/copyright, you cannot ship files using PHP License 2.02 or
> PHP License 3.0. This will be rejected by ftp-master.
That is what I feared at first (see #442361), but I found other
packages (like php-html-common,
http://packages.debian.org/changelogs/pool/main/p/php-html-common/current/copyright,
php-net-socket, php-xml-parser [3.0], all of which are in my
dependencies) that are under PHP License 2.02 and already included in
the archive.
> You seem to not
> ship most of those files but you still ship QuickForm. For other files,
> you should add a notice in debian/copyright that the files are not
> shipped with the package.
Very precisely, currently, the files of the dependencies _are_ in
upstream tarball (and in the source package), but not _used_ by my
package (using Debian packages instead). Do you mean I should remove
all those files from upstream tarball and create some repackaged
phpmyvisites.dfsg upstream sources?
> For QuickForm, does QuickForm2 is an acceptable drop-in replacement?
Not tried it yet. Upstream is
http://pear.php.net/package/HTML_QuickForm2 but from what I have read
(sorry I do not have the link at hand) it _seems_ that not, but I
should try then if the license problems really get in the way.
> You should use dbconfig-common to configure database. This is not very
> difficult and there is a lot of packages using it.
Yes, I am willing to do it, but (as I said in README.Debian) I fear
it will require quite heavy patching of upstream (there is an
installation procedure quite intricately included in the rest of the
code) and I am undecided about what would be the best way to do it. Do
you have some example of other packages PHP where only _parts_ of the
installation procedure has been diverted in order to take advantage of
dbconfig-common?
Should I completely rewrite an other installation procedure from
scratch with _many_ debconf questions and templates (won't it be a
debconf abuse?)? (I think it might be much simpler to implement.)
> You could also ship
> Apache configuration in /etc/apache2/conf.d (with a debconf
> question).
Yes, if I go using debconf, I can do this too.
> You can look at other web apps for some source of inspiration
> on this matter (mediawiki, roundcube, ...) or at the webapps draft
> policy.
Thanks again for your feedback. I will try to address all your
suggestions (the license problem, I fear, been the most problematic
one) and come back with an updated package.
Best regards,
Frédéric Lehobey
PS : I have fulfilled your Mail-Followup-To, but should
dbconfig-common questions go to -mentors, -webapps or both? (I do not
want to bother people). :-)
Reply to: