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 _______________________________________________ Pkg-grass-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel
