Re: Role of library packages in Blends tasks [Was: gis branch, master, updated. 44bb6e5b478da64af8f9feb145dd349c1d7a4b34]
Hi Bas,
On Sun, Mar 09, 2014 at 01:57:34PM +0100, Sebastiaan Couwenberg wrote:
> Hi Andreas,
>
> Thanks for the tips.
>
> libgdal1-1.10.1-grass is a bit of a special package, its source is
> extracted from the gdal source to avoid a circular dependency between
> GDAL and GRASS.
>
> When GDAL was updated from 1.9.x to 1.10.x the Blends Thermometer
> stopped reporting the versions in testing and unstable.
>
> No package depends on libgdal1-1.10.1-grass to pull it in, so it needs
> to be added explicitly to a Blends task.
>
> Hopefully this is a sufficient reason to include libgdal1-1.9.0-grass in
> the Blends tasks even though library packages are not normally added. If
> not, we need to update the Thermometer to handle source packages
> directly like DDPO and DMD do so I don't need to depend on
> libgdal-*-grass packages to find its source.
Well, finally *we* (in terms of the Debian GIS team) decide what is
mentioned in our tasks and we are responsible to our users to not create
confusion on their side. I think chances to do the later are not very
high so it is probably not harmful. However, I think we should find a
way to decouple our development tools (thermometer) from the users view
(tasks). I wonder whether we could reach this goal by simply renderint
packages that are tagged "Ignore". The use of this tag stems from some
Debian Edu and has the meaning: "Package is interesting for the project
but does not fit on our DVD." This is definitely something else than we
would like to approach but we could "missuse" it ... or find a dedicated
tag for our purpose.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: