Re: Debian GIS tasks layout (Was: [SCM] gis branch, master, updated. 3877275fba8820581da281fbbc32c3764c73baca)
On 10/15/2013 09:37 AM, Andreas Tille wrote:
> Hi Bas,
> I'm observing your recent commits and notice, that you are playing
> around with adding lib* packages to a user oriented Blend. The general
> philosophy is that a task should rather cover user *applications* (the
> library will be included via dependencies anyway). If you really want
> to add some information about libraries it rather seems to be developer
> oriented and may be should end up in a task
> or something like this were you put
> Depends: libspatialite-dev
> or something like this.
> In any case: If you confirm you understood this general philosophy but
> insist that your task layout makes sense that's fine for me - just to
> let you know.
I understand that the meta packages are to be installed by users.
The tasks serve the additional purpose of listing packages part of
Debian GIS to feed the thermometer.
A devel tasks seems like a good idea to put all Debian GIS -dev
packages. Then we can at least track all libraries that don't also ship
Currently librasterlite is part of the workstation task via its
rasterlite-bin binary package. Similarly libkml is part of the
workstation task via its java and python bindings, although these are
Because spatialite-bin was split from the spatialite package into its
own spatialite-tools source, the spatialite package providing the
library is not part of any task. Nor was the new libgaiagraphics
dependency of spatialite-gui part of any task.
Since there libraries will be installed because they're dependencies of
the task, I didn't see a problem in adding them explicitly for the
benefit of the thermometer.
AFAIK the thermometer only checks packages listed in the tasks files,
not their dependencies that would be installed when the meta package is.
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)