Re: Advice on packaging a PHP application (ITP for Shaarli)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Emilien,
On 06.01.2012 00:13, Emilien Klein wrote:
> Those files constitute the application. I am thinking about placing
> those in /usr/share/shaarli
That's all right. Please note, you must not write anything to this
directory though after installing anything to /usr/share you need to
make sure your script does not try to write there at runtime.
If you have any volatile data, e.g. such as uploaded files, generated
files and such make sure you use a proper directory for that. Have a
look to the FHS [1] to find a directory which suites best for your use
case, feasible examples could be /var/lib/shaarli or /var/cache/shaarli
> I plan to create an Apache configuration file under
> "/etc/shaarli/apache.conf". A symbolic link to this configuration file
> would be made by debian/postinst, linking it from
> "/etc/apache2/conf.d/". The content of this file would be something
> like this:
>
The approach by itself is ok, but please make sure you do not make the
link statically (i.e. in the package itself), but dynamically at runtime
in a maintainer script after detecting an Apache installation.
>
> Alias /links /usr/share/shaarli
This alias is too generic, why not "Alias /shaarli /usr/share/shaarli"?
> # some people prefer a simple URL like http://links.example.com
> #<VirtualHost 1.2.3.4>
> # DocumentRoot /usr/share/shaarli
> # ServerName links.example.com
> #</VirtualHost>
That's perhaps redundant as well. If people want to setup the
application by themselves, they do so anyway and won't use your
configuration at all.
> Next to that, Shaarli needs to create some folders/files in order to function:
> - A data subdirectory
> - A cache directory
> - A tmp directory
>
> By default, those directories are created in the same folder as where
> the application files are (that would mean under /usr/share/shaarli).
> Would /var/lib/shaarli be a better place to locate these folders? I
> would then patch the index.php file to point to these new locations.
Ah, I answered that already above. For the cache and tmp directories
/var/cache seems feasible. For the data directory you may want to use
/var/lib.
> Then a few random questions:
> - The current version number is "0.0.32 beta" (including space) as
> written on the web page and in the source code, and "0.0.32beta" in
> the zipfile. As the version number in Debian can't contain spaces,
> would you use "0.0.32beta", or even just drop the "beta" part and use
> "0.0.32"?
Gregoa answered that already.
> - By creating the Apache configuration file, I force the user to use
> the "/links" url. Is there a better way, for instance on defaulting
> with /links, but giving the option to change that using
> `dpkg-reconfigure` (which BTW isn't available on my sid install???) Or
> is there a way to mark this file as a config file, so that the user
> would be able to edit it and it wouldn't later be overwritten during
> an upgrade?
Sure, you can do that. I think it is probably not worth the effort and
quite challenging to do it right.
> - What about using the debian/postinst (and probably a corresponding
> debian/postrm)? The Debian New Maintainers' Guide specifically warns
> new users against using them [0].
Yes, but in your case you need a postinst script for making the link in
/etc/apache2/conf.d if required and needed (but see below).
> Both gallery and gallery2 use them
Don't be inspired by the gallery2 postinst script. It is a very bad
example and moreover most likely a severe policy violation (I will check
that later more detailed). The phpmyadmin postinst seems much more sane.
> - Should I handle more than just Apache2 (other webservers)?
That's up to you. At least, you should not depend on Apache and make
sure it works fine without installing Apache. A dependency like:
Depends: apache2 | httpd-cgi
is ok though.
> P.S.: Please CC me on your response as I'm not subscribed to the list.
Removing the Apache list though, as you're quite off-topic there.
[1] http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html
- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPBstPAAoJEMcrUe6dgPNtxwoQAKuGHMDkYQh5SHRK9Eq62wzl
8uHwFXCXeDJ6sBEza+ULZCDJfGplVEgLRTbHw2NO5tNjZWqf0y9ZZE49xod0hwXQ
BNoIQSs9Cq9bTfhVuOfptfFkfytR1Zwq+Qx0hpRBoMyZrB0u6Flh8e/hDhTPlbsd
mYbUXs7CzmhtZHbejFsDjmJNKVIimlr396JLIv2fCqo+SnJqOf6osco3WJmLNXJ5
rSmfV5buh2uv2/4KHzGjPaX8tFfHM5m9AAxOy+MFPuBnDUN7zvhLHOVfZgYeLkm3
ue6S/fzlEBG848iSlWp8wHIuxbW/ALLK3uihOL7ye92L5Gyhko3ymDR+yLAWoC/v
l/BixVwyv0Mc9JjouFp2vzWMFxY+lFwFj4F9KakvuQ66xxwpFSYP3Me/FL4GYdHh
vvQVwEzKHPgBu96vC9rpAq3/VppgTjuSoR2LAo7yQo44R7Gbh8aFZNWyEaEnb2xA
JGEFGFMf30cUxblemZr4oDxSooDstLM1Tc1uzdSiu9xdYRG7zwJZeTArQR+9Q9p+
wsSXCZcONIQBDo7IV3C0m+vovbXV9taVUCHHaa2om44Evo0eUzpwUhVukFbg2zW+
QmMv7uohf2VpQCxNtIhLuTLfo7n4SI4a2ZJj3KxIbgTdQ1mn7161rrL0/Q70bomZ
sdxpsOnYPzLab+nBaOFy
=hl+U
-----END PGP SIGNATURE-----
Reply to: