Re: Advice on packaging a PHP application (ITP for Shaarli)
Thanks Gregor, Thomas, Arno and Christian for your bits of wisdom. Summary:
I'll put
- the application files (which do not get modified) in /usr/share/shaarli
- the data/ directory in /var/lib/shaarli
- the cache/ and tmp/ directories in /var/cache/shaarli
I'll use the version name 0.0.32beta.
The package will not "hard-depend" on Apache. I'll create an Apache
config file with the alias "shaarli" that will only be linked to if
Apache is installed.
To respond to your points:
2012/1/5 Thomas Goirand <zigo@debian.org>:
> On 01/06/2012 07:13 AM, Emilien Klein wrote:
>> 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?
> Remember that /usr can be a read-only filesystem if one wants to, and
> your PHP thing should continue to work.
Thanks. Those applications files are static once installed, should be
alright then.
2012/1/5 Thomas Goirand <zigo@debian.org>:
> On 01/06/2012 07:13 AM, Emilien Klein wrote:
>> - 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?
>>
>
> The /links thing is too generic, and it might clash with other things. I
> wouldn't use it if I was you. In fact, I see no reason why you would force
> it at all. Just don't setup anything if possible, and do a README.debian.
> Just your <Directory> portion is enough.
I'd still prefer the package to be usable right out of the box,
without further configuration. I'll add the Apache configuration file
with an Alias of "shaarli", but only if Apache is detected, thus not
"hard-depending" on Apache (following Arno's suggestion below). Users
wanting more indepth control (other allias, or subdomain) will be able
to configure that by themselves. I'll specify all of this in a
README.debian though.
2012/1/5 Thomas Goirand <zigo@debian.org>:
> On 01/06/2012 07:13 AM, Emilien Klein wrote:
>> - Should I handle more than just Apache2 (other webservers)?
>>
> Nobody can force you to support anything, but *please*, do not
> force anyone into using Apache by adding dependencies to it.
> In my environment for example, I can install PHP packages,
> but no web server (I install things in a chroot...). We have a
> Recommends: field for things like that...
Will do.
2012/1/6 Arno Töll <debian@toell.net>:
> On 06.01.2012 00:13, Emilien Klein wrote:
>> 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.
That was what I had in mind. I'll make sure to not depend [solely] on
Apache, and only link the config file if Apache is installed.
2012/1/6 Arno Töll <debian@toell.net>:
> On 06.01.2012 00:13, Emilien Klein wrote:
>> Alias /links /usr/share/shaarli
>
> This alias is too generic, why not "Alias /shaarli /usr/share/shaarli"?
Seems like a good compromise.
2012/1/6 Arno Töll <debian@toell.net>:
> On 06.01.2012 00:13, Emilien Klein wrote:
>> - 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.
Hmm, that's indeed how it looks like. Let's not go that route then.
2012/1/6 Arno Töll <debian@toell.net>:
> On 06.01.2012 00:13, Emilien Klein wrote:
>> - 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.
I'll have a look at the phpmyadmin postinst then.
2012/1/6 Arno Töll <debian@toell.net>:
> On 06.01.2012 00:13, Emilien Klein wrote:
>> - 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.
Thanks for the tip.
2012/1/6 Christian Welzel <gawain@camlann.de>:
> Am 06.01.2012 11:22, schrieb Arno Töll:
>
>>> - 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
>
> Another approach would be to make an apache configuration package like
> shaarli-apache2. That leaves the choice to the user, and can force
> the installation of apache. And its very easy to add support for other
> servers later without breaking anything (shaarli-nginx, etc). If
> someone wants to implement his own integration he doesn't need to
> install the integration package and is just fine.
This indeed seems like an interesting approach, though the approach of
detecting Apache and adding a config file if it's present seems better
for now (I'm still very new to Debian packaging).
Thanks all,
+Emilien
Reply to: