[Git][debian-gis-team/libapache2-mod-tile][master] Completed changelog.

[Sebastiaan Couwenberg]

On 9/4/20 8:17 PM, Felix Delattre wrote:
> On 9/3/20 5:58 PM, Sebastiaan Couwenberg wrote:
>> Editing config files in maintainer scripts is fraught with danger. Have
>> you read the relevant policy section about that?
>>
>>  https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html
> 
> Yes, I had several rounds of thinking and I never ended up with a completely satisfying solution.
> 
> The problem is: renderd only supports one configuration file for all raster tile layer definitions one wants to get from mapnik.
> 
> Let me share with you my thoughts, and help me please to evaluate better:
> 
> * first, I thought, I do a packageconfig script joining all config files it finds under /etc/render.conf.d/ into renderd.conf; leave a suitable statement in renderd.conf, that people are not expected to edit this file but add their config in the renderd.conf.d directory as separate files. - similar to https://salsa.debian.org/tex-team/archive/tex-common/-/blob/master/scripts/update-texmf (and include a manpage of course)
> 
> * from this, I came to: a conf.d directory should be ideally be supported by upstream directly.

Yes, and with upstream development being practically dead, this will be
another diversion you'll have to maintain indefinitely along with all
the patches that aren't being merged upstream.

> * and I concluded, I use the simplest version of postinst config file manipulation with one explicit text block to be added and removed. which is a very strong constraint that should not mess with any other config data being applied by admins or changes through package upgrades. This for now, and consider extending upstream to handle conf.d later on.

A packageconfig script to manage the single renderd.conf with a proper
ini reader & writer (e.g. Python configparser.ConfigParser) is still an
option though.

> - of course, the other option is to discard entirely the `renderd-example-map` package. This is just a goodie for people to get started, but neither part of upstream nor necessary for running the system. Avoiding this entirely would not provoce this problem (neither include any shapefiles)
> 
> What do you think?

The last option is the most KISS, leaving out most complexity.

While it's great when installing a package get you a minimal running
service, leaving the configuration to the admin is fine too.

Documenting the steps to setup a simple tileserver, e.g. in
README.Debian, would suffice to help users get started.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1