Hi Antonio,
many thanks for your input!
On Thu, Mar 14, 2013 at 08:04:40PM +0100, Antonio Valentino wrote:
> > gmt-coast-low - Low resolution coastlines for the Generic Mapping Tools
> > gmt-gshhs-full - Full resolution coastlines for the Generic Mapping Tools
> > gmt-gshhs-high - High resolution coastlines for the Generic Mapping Tools
> > gmt-gshhs-low - Low resolution coastlines for the Generic Mapping Tools
> > --> ??? ('sar', or even to be created 'data'?)
> >
>
> there is some package in the remote sensing task that depends on GMT
> but IMO the coastline data can't be considered specific of that
> task.
>
> +1 doe data
OK, created data task containing:
Depends: gmt-coast-low, gmt-gshhs-low
Suggests: gmt-gshhs-full, gmt-gshhs-high
with the idea that low resolution data should be installed when a user
asks for the gis-data metapackage to enable running the intended
programs but only offer the full and high resolution data at explicit
request. Please confirm whether this makes sense.
> > libgdal1-1.9.0-grass - GRASS extension for the GDAL library
> > --> sar
>
> workstation IMO
OK, moved from sar to workstation
> > python-epr - Python ENVISAT Product Reader API (Python 2)
> > python-pyshp - read/write support for ESRI Shapefile format
> > --> workstattion (only suggested because API and no application -
> > see below)
> >
>
> python-epr is already in the remote sensing task but IMO workstation
> and/or dev is also OK
Thanks for the hint, left unchanged
> >featuring development library packages like for instance
> >
> > libepr-api2-dev, libgeo-proj4-perl, libgeotiff-dev,
> > libgrits-dev, libkml-java, python-kml, libkml-dev,
> > libterralib-dev, python-epr, python-pyshp, libreadosm-dev,
> > libspatialindex-dev
> >
>
> python-gdal IMO belongs to the same category
Yes, also a lot more *-dev, python-* packages. It needs to be
decided first whether we want to provide a general
gis-devel
package or whether we rather want to support more fine grained devel
tasks. The packages above were just examples without gaining for
completeness.
> the task file for the remote sensing task is currently sar.
> I don't know if the task file name has any relevance in the process
> of metapackages generation.
The metapackage becomes: gis-sar.
> If it does you should consider to rename the task file: remote
> sensing is a wider scope with respect to SAR (Synthetic Aperture
> Radar)
We should decide about a proper name right now because there is not yet
any debian-gis metapackage set released. Once it is released with this
name it becomes harder to change afterwards. I'm fine with any choice
that makes a proper (i.e. not too longish) package name.
Thanks again for your input
Andreas.
--
http://fam-tille.de