Bug#448532: RFS: phpmyvisites -- free web analytics

[Frederic Lehobey]

Dear mentors,

I am looking for a sponsor for my package "phpmyvisites".

* Package name : phpmyvisites
Version : 2.3-1
Upstream Author : phpMyVisites team
* URL : http://www.phpmyvisites.us/
* License : GPL-any
Section : web
Programming Lang: PHP
Description : free web analytics

phpMyVisites is a free and powerful open source (GNU/GPL) software for websites
statistics and audience measurements.
phpMyVisites gives a lot of information on websites visitors, visited pages,
software/hardware utilization, etc... The GUI Interface is fun and practical.
The installation is entirely automated and very simple.
Statistics are very complete and use many clear graphics to present data. The
web analytics software is translated in more than 30 languages!

It builds these binary packages:
phpmyvisites - free web analytics

The package appears to be lintian clean.

The upload would fix these bugs: 448532

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/p/phpmyvisites
- Source repository: deb-src http://mentors.debian.net/debian unstable main
- dget http://mentors.debian.net/debian/pool/main/p/phpmyvisites/phpmyvisites_2.3-1.dsc

I would be glad if someone reviewed and uploaded this package for me.
It is my first php package. I have mostly taken inspiration from
dokuwiki package (and some others).

It does not uses debconf nor dbconfig-common yet but both might be
introduced in the future for package configuration (with heavy changes
to upstream though: I will follow advice from mentors and sponsor).

Kind regards
Frédéric Daniel Luc Lehobey

[Vincent Bernat]

OoO En cette nuit nuageuse du jeudi 15 mai 2008, vers 01:02, Frederic

Post by Frederic Lehobey
I am looking for a sponsor for my package "phpmyvisites".

Hi Frederic!

php4 will not be part of lenny, therefore, you can remove php4
dependencies. Moreover, php5 depends on libapache2-mod-php5. You can
drop "Suggests" too. I don't know if the content of artichow/php4 could
be dropped too.

You short description is very short. You may want to complete it a
bit. You should add a blank line in the long description.

About debian/copyright, you cannot ship files using PHP License 2.02 or
PHP License 3.0. This will be rejected by ftp-master. 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.

For QuickForm, does QuickForm2 is an acceptable drop-in replacement?

You should use dbconfig-common to configure database. This is not very
difficult and there is a lot of packages using it. You could also ship
Apache configuration in /etc/apache2/conf.d (with a debconf
question). You can look at other web apps for some source of inspiration
on this matter (mediawiki, roundcube, ...) or at the webapps draft
policy.

[Frederic Lehobey]

Hi Vincent,

Thanks a lot for your feedback. A first round of answers.

Post by Vincent Bernat
OoO En cette nuit nuageuse du jeudi 15 mai 2008, vers 01:02, Frederic
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.

Post by Vincent Bernat
Moreover, php5 depends on libapache2-mod-php5. You can
drop "Suggests" too.

Ok. Thanks.

Post by Vincent Bernat
I don't know if the content of artichow/php4 could
be dropped too.

Probably, yes.

Post by Vincent Bernat
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.

Post by Vincent Bernat
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.

Post by Vincent Bernat
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?

Post by Vincent Bernat
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.

Post by Vincent Bernat
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.)

Post by Vincent Bernat
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.

Post by Vincent Bernat
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). :-)

[Vincent Bernat]

OoO La nuit ayant déjà recouvert d'encre ce jour du mercredi 21 mai

Post by Frederic Lehobey

Post by Vincent Bernat
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.

I don't remember exactly how this is handled, but those licenses are
accepted only for PHP, as per REJECT FAQ:
http://ftp-master.debian.org/REJECT-FAQ.html

I suppose that the packages you cite were here before this
statement. There are bugs filed in this case. For example, for
php-net-socket:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332616
(not a very active bug)

This is quite unfair that already packaged packages can keep the
problematic PHP license and that new softwares are automatically
rejected on this basis. You might ask on debian-legal if the situation
has somewhat evolved on this situation.

Post by Frederic Lehobey

Post by Vincent Bernat
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?

No, those files are allowed to be distributed freely. Just add a note
(above the license) to tell that those files are not shipped in binary
packages. Otherwise, ftp-master might be a bit quick to reject the
package.

Post by Frederic Lehobey

Post by Vincent Bernat
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?

I do it for text-pattern: I just create the empty database and let the
installation scripts (a bit patched) do the remaining. This is quite
intrusive and difficult to maintain: textpattern was also trying to
create the database. Since this is not the case for phpmyvisites, you
can try to just create an empty database with dbconfig-common and let
phpmyvisites handle the remaining installation procedure.

Post by Frederic 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). :-)

Well, mentors is a good place for all kind of questions. And webapps is
a good place too since we are talking about a webapp.

[Xavier Luthi]

Hi Frederic,

Post by Frederic Lehobey
[...]

Post by Vincent Bernat
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.)

Im' using dbconfig-common to configure database for my pixelpost[1] package. I've replaced all the installation procedure built into the upstream sources by dbconfig-common and one additional debconf template.

Hope this can help you...

Cheers,
Xavier

[1] http://packages.qa.debian.org/p/pixelpost.html

Post by Frederic Lehobey

Post by Vincent Bernat
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.

Post by Vincent Bernat
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). :-)
--