> 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
