I have three suggestions:
1) the suggested way is to run Radicale with Apache and UWSGI. Therefore,
libapache2-mod-proxy-uwsgi is necessary and not to be marked as suggested.
Using Radicale with uWSGI is _suggested_ and therefore the package
_suggests_ libapache2-mod-proxy-uwsgi.
if instead treating libapache2-mod-proxy-uwsgi as necessary, using
Radicale with uWSGI becomes mandatory, which is not intended.
I agree that it makes sense to improve the package to better work
out-of-the-box, but I disagree that the way to do that is to reduce
flexibility of the package: It is usable with uWSGI or without uWSGI.
I am interested in discussing how the package could be made easier to
use *without* limiting the ways it can be used. I hope you will be
interested in discussing that.
Ok, I get your point.
In radicale.README.Debian at the point '## Apache via uWSGI with PAM
authentication' it says: 'Install needed packages:' with some packages
to install. But not libapache2-mod-proxy-uwsgi . This is missing. The
brutal thing is, that the error messages in log files did not show that
this package is missing (at least not for me).
2) there must be a hint that changing filesystem_folder in /etc/radicale/config
needs changes in /etc/uwsgi/apps-available/radicale.ini and maybe in the home
directory of user radicale.
I disagree that consequences of each specific deviating from the default
setup needs to be documented in the package.
Right, this is not a must. But why not putting such information in the
readme file? The radicale package is really made well and almost works
out of the box. It's only a few pieces missing which has prevented me
from having it up and working within one hour. So why not putting them
there? It helps tremendously.
Using a distribution like Debian gives me the possibility to run my own
free services although I may not know much about Apache, UWSGI, CalDav
etc.. And I am infinitely thankful to packagers like you how do the
work such that others can use it with very little work. This really serves.
So my wish is to have that much information available for each package
that I can use it without doing research in the internet for hours.
I am sorry that you made a change that you did not (until several days
struggle) realize had consequences at other configurations as well
This part wasn't that bad as the one above because there were some hints
in the log files.
Concretely, I consider the change of data location too fundamental to
sensibly document. Similar to how sudo only warns broadly about the
risks of being root but does not document all the risks - e.g. does not
say "don't do 'rm -rf *' while standing in the root directory" or "don't
use sudo while drunk, because you might mistype commands".
3) the description in radicale.README.Debian needs to be extened. I am willing
to contribute an explaination that would have empowered myself to have the
service up and running in a short time. This should be helpful for others, too.
Please share your suggestions for improvements. Or maybe begin by
sharing which ideas for improvements you have - because it sounds like
you would like far more detailed documentation than I am willing to
maintain, so probably better that we discuss the _ideas_ that you have
before you spend too much time turning your ideas into concrete text.
There isn't too much that I would add to the readme file. There is much
documentation about Radicale on its web page. But for someone who hasn't
worked with uwsgi before it's not clear how everything works together.
And being asked adapt the config file as needed produced quite a few
question marks in me.
So my remarks about adapting /etc/radicale/config are:
.) Everything in section [server] will be ignored
.) Authentication will be done by Apache, so leave type=remote_user in
section [auth] and you are done.
.) If you change filesystem_folder be aware that this is also written in
radicale.ini and as home directory of user radicale.
apache2-vhost.conf: I am doing authentication via htaccess and there is
lots of information about it around. But for the ones who have never
worked with Apache a few words how this conf file fits in into the whole
can really serve and make setup easy.
This are my thoughts about the package. I just would like to prevent
others to fall into the same traps as I did and not having them to go to
the next package or to Google etc for synchronization.
Best regards,
Florian.
