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
Attachment:
pgp6QitanKj36.pgp
Description: PGP signature