[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GEOS 3.5.1/3.6.0



On 11/09/2016 06:45 PM, Jochen Topf wrote:
> On Wed, Oct 26, 2016 at 06:36:52PM +0200, Sebastiaan Couwenberg wrote:
>> osmium (0.0~20160425-e2e4368-2) FTBFS due to the same issue.
>> Reported upstream in: https://github.com/joto/osmium/issues/100
>> Since osmium has been deprecated in favour of libosmium, a fix for this
>> issue is unlikely. But perhaps the fix is easy and we can just patch it.
> 
> I think it is time to retire the old Osmium. It has not been supported
> for years now and I am not aware of any supported software that still
> uses it. If anybody needs it, they can still get it from source. It is
> a header-only library after all, so this is not a huge burden.
> 
> I don't think it is a good idea to keep it around for another three
> years or so until the next stable arrives after Stretch. This is just
> too long a time for a software that is already hopelessly out of date.
> Especially because it is rather confusing for new users who sometimes
> find the old osmium rather than the new libosmium and are confused if
> nothing fits the documentation they find on the web.

Alright, we'll force users to migrate to the new osmium family.

Removal requested: https://bugs.debian.org/843798

>> libosmium (2.9.0-2) FTBFS due to the same issue too.
>> Reported upstream in: https://github.com/osmcode/libosmium/issues/168
> 
> The next version of libosmium will deprecate the use of GEOS. As far as
> I know, nobody is using it and the approach using the C++ API of GEOS is
> wrong anyway, because the GEOS project considers this to be internal and
> recommends use of the C API. I have added a check to the code which will
> disable building of the parts that use GEOS for versions from 3.6
> onwards, so it shouldn't stand in the way of upgrading GEOS, but will
> keep working with older GEOS versions.

Thanks, we're not going to transition to GEOS 3.6.0 any time soon. The
transition freeze was last weekend, so no more transitions until the
stretch release.

Because ossim & osm2pgsql also don't support GEOS 3.6 yet, we can't
consider it for inclusion in Debian yet. Not having ossim will mean the
removal of otb which has received considerable effort to get included in
stretch.

The transition to GEOS 3.6 will happen during in the buster development
cycle sometime next year. Hopefully osm2pgsql has by then switched to
libosmium and therefore no longer requires geos, and ossim has switched
to the C API.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


Reply to: