severity 402406 important thanks On Mon, Dec 11, 2006 at 10:26:32PM +0100, Daniel Rodriguez Garcia wrote: > Therefore, I think the problem here is time. It would be a pity to lose > this package for this "silly" thing.
License issues are not a "silly" thing. They are rather important if we want to ship a free OS. > Possible alternatives: > > 1) Cut out the graphics rendering functionality from ACIDBASE (not > really essential, for me). A link for exporting data to a spreadsheet > format would be enough. Currently I think that's the only viable option, remove the php-image-graph *and* ensure the package can work without it. I agree with Jeremy that providing a package that does not Depend: on php-image-graph but asks the user to use a mechanism which is outside the Debian package management system to install needed functionality is a no-no. If the dependency is removed then the maintainer must ensure that the package can fully work without it, even if that means stripping of PHP pages that depend on that library. That would imply (doing a cursory look at the PHP code): - remove the link from base_main.php to base_graph_main.php - do not include base_graph_form.php in base_main.php - modify base_graph_common.php so that it does not complain so loudly when Image/Graph is not found. Just say that the functionality is currently not available in Debian (due to license issues, point to the Bug report) and say that users that need it will have to install the PEAR modules. - document in NEWS.Debian why the graphs have been removed and when will they be reenabled in the front page. For reference, the bug to be referenced is #401797 *and* #402406 (do not reference #340730 or #335994) That way users will not "see" the PHP scripts used to make graphs and they will not (going through the GUI) get a big error saying "you are missing something". While at the same time, users depending on them will still be able to reach the PHP scripts and see what happened. Does that sound like a plan? David, could you please change that and test that the changes I outline are sufficient? > 2) A text based histogram (similar to that in main screen)? That would mean implementing something that substitutes the current functionality, not something feasible to do right now if we want to get this into etch. > 3) Implement that functionality as a Java applet ?? i.e. optional > functionality: you leave the problem of installing Java in their > browsers to client users. That's also a no-no (you would get into the issue of how to compile the Java code to build the jar). Either the functionality is available for all users using *only* the Debian archive or it's not. Having people go through loops is uncalled for. Regards Javier
signature.asc
Description: Digital signature