Portfiles for an OpenStreetMap Tile Server

[Frank Dean]

Craig Treleaven <ctreleaven at cogeco.ca> writes:

>> On Aug 29, 2021, at 8:02 AM, Frank Dean <frank at fdsd.co.uk> wrote:
>> 
>> I have a few questions to ask in relation to a series of Portfiles that
>> I have created to support installing and running a map tile server for
>> OpenStreetMaps [1].
>> 
>> [1]: https://switch2osm.org/serving-tiles/
>> 
>> The logical Portfiles:
>> 
>> - libprotozero - library required by libosmium
>> 
>>    https://github.com/mapbox/protozero
>> 
>> - libosmium - library required by osmium-tool
>> 
>>    https://github.com/osmcode/libosmium
>> 
>> - osmium-tool - application required at runtime by mod_tile/renderd
>> 
>>    https://github.com/osmcode/osmium-tool
>> 
>> - osmosis - Java application required at runtime by mod_tile/renderd
>> 
>>    https://github.com/openstreetmap/osmosis
>> 
>> - openstreetmap-carto - style sheets used by mod_tile/renderd
>> 
>>    https://github.com/gravitystorm/openstreetmap-carto
>> 
>> - mod_tile/renderd - the OpenStreetMaps tile server
>> 
>>    https://wiki.openstreetmap.org/wiki/Mod_tile
>> 
>> 1.  Should I submit each Portfile in dependency order and await its
>>    acceptance before submitting the next in sequence, or submit them
>>    in dependency related batches in a single pull request?
>> 
>> 2.  The primary port is 'mod_tile' which contains an Apache module for
>>    serving the tiles and a 'renderd' daemon that renders and creates
>>    tile images based on requests from 'mod_tile'.  Both artefacts are
>>    created in a single build.
>> 
>>    I have currently named the port 'renderd', but the project is
>>    commonly known as 'mod_tile'.  Naming the port 'renderd' was the
>>    only way I could succeed in the 'renderd' startup item being loaded
>>    via the 'sudo port load ${subport}' command.
>> 
>>    Is there a better way of naming and creating this port, perhaps as
>>    subports?
>> 
>> 3.  Getting the tile server up and running requires quite a number of
>>    steps.  I have created a shell script to largely automate the
>>    process.  At runtime it uses scripts from both 'openstreetmap-carto'
>>    and 'mod_tile/renderd', so doesn't immediately sit comfortably being
>>    installed with either of them.
>> 
>>    Is it best to create a simple separate standalone port (without an
>>    upstream project), containing just the shell script, naming it
>>    something like 'osm-tile-server' and depending on the other two
>>    ports; or simply include it in one of the other ports with runtime
>>    checks for the existence of required executables with helpful error
>>    messages when they're absent?
>> 
>> Many thanks,
>> 
>> Frank
>
> I’ll offer my thoughts to get the ball rolling.  First, from briefly looking over the involved projects, this is a relatively complex set of ports so be prepared that it may take some time to get everything working properly.  Good on you for tackling this!
>
> Do you have some support upstream?  AFAICT, mod_tile seems to pretty much only on Debian at this point.  
>
> Re your questions:
>
> 1) I think you should add the ports in dependency order rather than one submission including everything.  These days, pull requests tend to get acted on more quickly than tickets.  If you haven’t seen it, we have a wiki page about MacPorts and git at:
>
> https://trac.macports.org/wiki/WorkingWithGit <https://trac.macports.org/wiki/WorkingWithGit#CommongittaskswhileworkingwithMacPortsbase>
>
> You can submit multiple pull requests at once.  Just add links to the other related PRs so anyone reviewing will know that there is a series.
>
> 2) I see that the GitHub project is named “mod_tile” while Debian has called their package "libapache2-mod-tile”.  MacPorts has several ports named mod_foo so I think mod_tile makes the most sense.
>
> https://ports.macports.org/search/?installed_file=&q=mod_&name=on <https://ports.macports.org/search/?installed_file=&q=mod_&name=on>
>
> Re the startup item, I think you should be able to use the startupitem.name and startup item.executable keywords to make the renderd daemon work as required.  No?
>
> https://guide.macports.org/#reference.startupitems <https://guide.macports.org/#reference.startupitems>
>
> 3) Without seeing the shell script you’ve developed, it is difficult to say whether you should add it to the mod_tile port or port it in a standalone port.  I would lean towards including it in mod_tile.  Perhaps you could submit it upstream for inclusion in a future release?
>
> Hope this helps,
>
> Craig
>

1) That makes sense.  I'll add them separately with links to the related PRs.

2) I had created my own plist file as I couldn't see a way of specifying
   a specific user to run the daemon as, but your mention of
   startupitem.executable encouraged me to re-read the docs, and then
   look in 'portstartupitem.tcl' which documents startupitem.user.  So I
   now have the portfile working and named 'mod_tile' with the daemon
   named 'renderd'.  I'll submit an update to the documentation for
   'startupitem.user'.

https://github.com/macports/macports-base/blob/master/src/port1.0/portstartupitem.tcl

You are quite correct that they are a complex set of ports and they did
indeed take some time to get working properly.  I'm still testing and
refining the Portfiles as I learn more.  Hopefully I'll soon have them
ready to submit as PRs.  No doubt there will be more work consequent to
that.

I'll offer the shell script upstream.  From comments I have read, I get
the impression upstream are only really interested in Linux based
distributions, but there was just one small patch required to compile on
macOS and it seems to run just fine.

Many thanks.  That's been very helpful.

Cheers,

Frank