Hi Jason, I think we have talked before about the password-store project. I'm back again for the Photofloat project, a great tool you have written and I'd like to see in Debian eventually.
There are a few hurdles to go through unfortunately, on the Debian side. I write to you to get your feedback about this effort, to see how you as an upstream can collaborate with this. However, I totally understand if you do not have time to respond or do not wish to change photofloat for it to be packaged in Debian, in which case you should feel free to ignore this email. Here are the tasks that are necessary for the package to be accepted in Debian after an inspection of the code. 0. rename the binary 1. have numbered releases? 2. remove external libraries 3. separate code from data 4. default gallery and multi-gallery support I expand each point below. 0. Rename the binary -------------------- This one is much simpler - the python processor should simply be named something else than main.py (maybe photofloat.py?) so it can be installed in the $PATH. This can be done in the build stages of the Debian package. 1. Numbered releases -------------------- To simplify packaging and tracking of this software, tags in the git repository or better tarball releases would be useful. Otherwise the software will be released based on timestamps, the proposed first version is for example called 0~20121124+f7f92c1 - not pretty! :) 2. External libraries --------------------- The following libraries are shipped with the upstream tarball and will need to be removed before the upload into Debian: * jquery 1.7.2 (already in Debian) * jquery-hashchange.js 1.3 (not in Debian, not planned) * jquery-fullscreen.js 1.0 (not in Debian, not planned) * jquery-mousewheel.js 3.0.4 (already in Debian, as jquery-goodies) * yuicompressor 2.4.6 (2.4.7 already in Debian) * htmlunit 2.8 (already in Debian) * google-compiler (not in Debian, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622928) * fonts/* (already in Debian, package lmodern) Some of those are not problematic, because they are not packaged in Debian at all, it's technically allowed to ship them. Those are google-compiler, hashchange, fullscreen and mousewheel. google-compiler is being packaged however, so that may be a dependency... Tools like jquery, yuicompressor and HTMLunit will inevitably lead to the Debian package having special procedures to link against those builtin packages instead of relying with the upstream distribution. Those mechanisms can stay in the Debian package, but if they would be part of upstream, that would be better. In any case, the Debian package's tarball cannot feature most of those libraries, since it's part of the Debian policy to avoid shipping duplicate copies of code, as it makes security maintenance much harder. The solution for the Debian side is to simply create a new tarball without those files. For upstream, the solution could be to remove those and download them on the fly when building. 3. Code and data ---------------- It's pretty cool that you provided instructions to install what is after all a personnal project. :) However, the way an album is created is not exactly compatible with Debian's strict file hierarchy standards, which follow the FHS with exceptions: http://www.debian.org/doc/debian-policy/ch-opersys The main problem is within the web/ directory. This directory, in the default configuration, contains both data (the images and cache) and code (HTML, javascript and CSS files). Ideally, a shared copy of the code would sit in (say) /usr/share/photofloat/web/ and symlinks (or whatever) would be created to that within the webroot where the gallery data is actually stored. I don't exactly know how images are loaded, and if it's possible to have them in a completely different location, so I would welcome your input on that. Having this feature would enable administrators to offer a gallery service to multiple users with minimal maintenance. 4. Default gallery and multi-gallery support -------------------------------------------- Naturally, this brings us to the idea of having multiple galleries. I was thinking of providing a default gallery with a cron job to automatically build it and a entry in the Apache configuration. Another tool could be one to create a separate gallery, which could be documented in the README.Debian file. A. -- Le pouvoir n'est pas à conquérir, il est à détruire - Jean-François Brient, de la servitude moderne
pgppWv0zOwc77.pgp
Description: PGP signature
