Re: osm-tile-server
> You should be able to get it to run by installing the package, and then
> running dpkg-reconfigure tilelite .
No, I tried this as well yesterday. There is something missing for it
to work out of the box afaics.
> Secondly, the questions are asked if the user has configured debconf to
> ask questions of that priority, you can go off the default value for
> that, but really its up to the user, so lowering the priority does not
> make much sense to me.
The priority is now "high", which will make the questions appear
during "apt install" on 99 % of all computers. By default,
"dpkg-reconfigure" shows questions with all priorities. So lowering
the priority will in general make the questions invisible when
installing, but visible when running dpkg-reconfigure.
> Also, it makes sense for the openstreetmap-carto package to allow the
> user to change the database the style.xml file is configured to use, as
> that is required for it to function properly once installed.
>
> If there is a issue with it not allowing you to use the same stylesheet
> for two different databases, it seems to me that the best (worst)
> solution is to extend the debconf scripts for openstreetmap-carto to
> allow for copying the file, and changing the database in the copy.
>
> This probably has multiple advantages over a separate package doing the
> copying, for example, openstreetmap-carto can handle regeneration of the
> copies when the package updated, such that they don't get ignored or out
> of sync.
Regeneration of the files when it is upgraded is very conveniently
handled by dpkg triggers. This is what I have done for
osm-tile-server.
> In summary, trying to avoid using the openstreetmap-carto package to
> handle the style.xml file it contains is a bad idea, as you cannot
> control the questions it asks the user, or how it handles
> upgrades/removals from another package.
>
> This makes it clearer to me that having a setup where the configuration
> for each part of the tileserver stack is handled by the respective
> component packages is more complex, but has less problems than trying to
> write a package or set of packages that wrap around it.
I do not agree with your conclusion. Remember that we are not talking
about having a wrap-around package that handles the configuration of
these packages themselves. We are talking about a package which uses
"instances" of these packages to make an "application". The component
packages themselves actually don't need to be aware of this
"application"-package. They can be considered sort of as library
packages.
I'm quite happy now with osm-tile-server for my own use now. I've been
able to spin up a OSM tile server from scratch with maps already
imported (small countries) in less than 5 minutes on DigitalOcean
using the package, compared to an hour of fiddling around before. I
don't see any other problems than that I get one irrelevant question
from one of the "component" packages when installing. I do however see
several problems with having the configuration spread out all over the
place: being asked the same questions over and over again, and
demanding that the user understands how the different questions relate
to each other in order to get a workable configuration.
I think having the configuration spread all over the place is both
more complex to maintain (many packages must be uploaded to tweak the
configuration), is not user-friendly, and is less friendly to other
"applications" that may come up and will depend on some of these
component packages.
Best regards,
Ruben
Reply to: