http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8007
Robin Sheat <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |Failed QA --- Comment #107 from Robin Sheat <[email protected]> --- (In reply to Tomás Cohen Arazi from comment #106) > Couldn't you just choose a PDF library that is shipped with Debian? :-D Seconded! > I successfully built both > - libpdf-writer-perl > - libpdf-fromhtml-perl > on Jessie but I need to check with Robin. Maybe he would let me build those. > I put this one on hold for a couple days (it works, I like it). It'll need to build on Wheezy, too. That might be fine, or maybe it won't be. I'll have a look when I get some other people-wanting-dependencies-that-don't-exist issues sorted. I am curious why we need multiple PDF writing things though, is it not possible to standardise around one? (and fair enough if it's not, but I'd like it to be considered before just adding in dependencies.) Tomás: You can build the packages if you like, so long as they would get into debian :) (or, to be honest, if they pass lintian with pedantic=yes and the pkg-perl profile applied, that's usually 90% of the work done right there. It's about time I started scripting more of the deploy process, and someone else doing stuff with it would make that more necessary.) > There's also a new non-Perl dependency python-pisa. It definitely needs to > be added to control.in on the koha-deps section for this to be pushed. Gar. We literally just removed python as a dependency. Like, a couple of weeks ago. Oh well. Unrelated to the packaging, and I'm not sure if this is a problem, but it looks like files are generated as borrnum/borrnum+date.tar.gz, and this is a totally predictable filename. Is this an OK thing to have? Also, should paths be a system preference? Should library staff be able to change the web paths and file paths on the system? That seems like something that is out of the scope of library policy and well into the scope of systems admin, and so defined in koha-conf.xml. My litmus test there is "does it make sense for library staff to be able to change this.", and in a case like this, I contend that it's meaningless. It also makes it harder for installation processes to set it to something that suits the distribution. Actually, the more I think about it, the more of a problem that last part is, as it means there's no way to have a "default works" situation, and there's no way you could expect library staff to fill out a path on the system. Additionally, this should be creating directories under /var/lib/koha/instancename/ as part of koha-create-dirs to put these files, and alias to them in the appropriate apache template. Other misc things: * discharges.pl has no error handling, it just blindly attempts to open a file and send it. What if the file doesn't exist? It looks like you'll then end up with people saving those PDF files that really contain an error message that confuses everyone. * related, there are other places where files are opened and everything is assumed to be OK. Can we stop assuming that everything is going to be OK? It causes too many problems when it's not. Code defensively, handle errors sensibly. * the RFC talks about mailing things, but I can't see in the patches where that happens, does it exist? I was trying to verify it was using the mailqueue, as the RFC implies (but doesn't say) that it doesn't. I'm going to make it failed because there's a good few things in here that need to be considered. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
