On 06-09-15 22:15, Ruben Undheim wrote:
>>> What I intended with the packages I've been working on was that the
>>> tilelite package itself does not install any daemon process, but the
>>> "osm-tile-server-tilelite" package installs the daemon process.
>>> osm-tile-server-tilelite depends on both osm-tile-server-base and
>>> tilelite, and osm-tile-server-base itself depends on
>>> openstreetmap-carto. This means that both openstreetmap-carto and
>>> tilelite will have been fully configured before the tilelite daemon
>>> starts. Doesn't this seem to solve the problem you describe?
>> It does, but it means that some of the configuration handling for the
>> tilelite package sits in a completely separate package, which feels a
>> bit off.
> I understand your point, but I do sort of see it a little bit
> differently. I consider this OpenStreetMap use of tilelite as just an
> "instance" of tilelite. It should be possible to still use tilelite
> for other purposes while the "OSM instance" is running. Tilelite is
> sort of a simple tool adhering to the Unix philosophy of doing one
> thing and doing it well. Therefore I think that a specific use of it
> should be captured by one separate package which does what is expected
> of it. osm-tile-server-tilelite="uses tilelite for the purpose of an
> OSM tile server". Then the configuration of this tilelite-instance
> will be fully captured by the osm-tile-server-tilelite configuration,
> and it will not interfere with other use of tilelite at all. It would
> be nice to hear what other experienced Debian people think about this
We should have a look at some of the other Blends, some of them have
configuration packages that do something similar (e.g. Debian Edu).
Maybe blends-dev is a good place to improve the metapackage generation
to have it support osm-tile-server like packages.
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1