Hi Vincent, Thanks a lot for your feedback. A first round of answers.
Vincent Bernat <[EMAIL PROTECTED]> (2008-05-21 22:03:52) : > OoO En cette nuit nuageuse du jeudi 15 mai 2008, vers 01:02, Frederic > Lehobey <[EMAIL PROTECTED]> 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). :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]