Even Rouault writes:
>> What I menat is that in the text of NEWS, you should not say that
> the C
>> ABI is unchanged. A "ABI has not changed" statement implies that
> one
>> can swap in the new binaries without rebuilding any depending
> packages.
>
> That would be true: you could replace t
On 5/3/20 10:05 PM, Even Rouault wrote:
>> It's indeed not possible to make everybody happy, so the question is who
>> you do mind the least to make unhappy.
>>
>> If nothing changes packagers like me will be unhappy because they need
>> to reintroduce the virtual dependency for the unstable C++ AB
> What I menat is that in the text of NEWS, you should not say that
the C
> ABI is unchanged. A "ABI has not changed" statement implies that
one
> can swap in the new binaries without rebuilding any depending
packages.
That would be true: you could replace the .so of GDAL 3.0 by the one
of 3
Even Rouault writes:
>> Not 100% sure I followed, but: If you change the shlib major
> number,
>> you have changed the ABI, even if the symbols are the same.
>
> Yes, but the reasoning is actually the reverse: the (C++) ABI has
> changed, so given libgdal contains both a C and C++ API, we
> h
> Not 100% sure I followed, but: If you change the shlib major
number,
> you have changed the ABI, even if the symbols are the same.
Yes, but the reasoning is actually the reverse: the (C++) ABI has
changed, so given libgdal contains both a C and C++ API, we
have to bump th shlib major number.
Even Rouault writes:
>> It's indeed not possible to make everybody happy, so the question is who
>> you do mind the least to make unhappy.
>>
>> If nothing changes packagers like me will be unhappy because they need
>> to reintroduce the virtual dependency for the unstable C++ ABI.
>>
>> C-only
> It's indeed not possible to make everybody happy, so the question is who
> you do mind the least to make unhappy.
>
> If nothing changes packagers like me will be unhappy because they need
> to reintroduce the virtual dependency for the unstable C++ ABI.
>
> C-only users will be unhappy about h
Sebastiaan Couwenberg writes:
> It's indeed not possible to make everybody happy, so the question is who
> you do mind the least to make unhappy.
>
> If nothing changes packagers like me will be unhappy because they need
> to reintroduce the virtual dependency for the unstable C++ ABI.
>
> C-only
Even Rouault writes:
> Answering Bas'
>
>> If you don't want that, then two libraries need to be built with their
>> own library versioning.
>
> and Gregs'
>
>> This doesn't make sense. The current/revision/age needs to be handled
>> differently for the C library and the C++ library, because in
On 5/3/20 9:15 PM, Even Rouault wrote:
> Answering Bas'
>
>> If you don't want that, then two libraries need to be built with their
>> own library versioning.
>
> and Gregs'
>
>> This doesn't make sense. The current/revision/age needs to be handled
>> differently for the C library and the C++ l
Answering Bas'
> If you don't want that, then two libraries need to be built with their
> own library versioning.
and Gregs'
> This doesn't make sense. The current/revision/age needs to be handled
> differently for the C library and the C++ library, because in feature
> releases one of them doe
Even Rouault writes:
[I'm behind in dealing with gdal, but otherwise would be in the same
boat as Bas]
> There has been obviously a misunderstanding. The rule we follow is that:
> - between GDAL X.Y.Z and X.Y.(Z+1), both C and C++ ABI are stable
> - between GDAL X.Y and X.(Y+1), the C ABI is sta
On 5/3/20 8:10 PM, Even Rouault wrote:
>> Why wasn't the SONAME bumped to reflect the ABI breakage?
>
> For me, SONAME bump was meant for the C ABI. I don't think this was intended
> for the C++
> one.
They share the same library, so the SONAME covers both.
If you don't want that, then two lib
> Why wasn't the SONAME bumped to reflect the ABI breakage?
For me, SONAME bump was meant for the C ABI. I don't think this was intended
for the C++
one.
> We dropped the virtual dependency that required rebuilding for every
> GDAL version change because you claimed that this wasn't required an
On 5/3/20 7:47 PM, Even Rouault wrote:
> Looking at what is presumably the native side of ogrListLayers(),
> https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/blob/master/src/ogrsource.cpp#L1090
>
> I see it use thes GDAL C++ API. Given that the C++ ABI can change between
> GDAL feature
> relea
On 5/3/20 7:36 PM, Edzer Pebesma wrote:
> In the r-cran-sf logs, I find:
>
> autopkgtest [09:48:59]: build not needed
>
> But if a new version of GDAL was just installed, a build would have been
> needed (assuming we use dynamic linking).
GDAL did not bump the SONAME, so it claims to be ABI comp
On dimanche 3 mai 2020 19:22:11 CEST Sebastiaan Couwenberg wrote:
> On 5/3/20 7:09 PM, Even Rouault wrote:
> > Looking at
> > https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/52035
> > 87/log.gz , there doesn't seem to be much detail about what fails
> > exactly.
>
> From the
Hi Bas and Even,
I'm the author/maintainer of the sf package; Roger and I both follow
this list actively. Neither Roger nor me have been involved (nor
consulted, at least I wasn't) in the creation of the r-cran-sf or
r-cran-rgdal packages. I'd be happy to check out what is wrong, but have
no clue
On 5/3/20 7:09 PM, Even Rouault wrote:
> Looking at
> https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/5203587/log.gz
> ,
> there doesn't seem to be much detail about what fails exactly.
From the log:
autopkgtest [09:49:06]: test run-unit-test: [---
..
Roger,
For my understanding, are the failing tests mentioned by Bas maintained by the
rgdal project
?
I assume they must be run by
https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/blob/master/debian/tests/run-unit-test
and the actual tests are:
https://salsa.debian.org/r-pkg-team/r-cran-rgdal/
Perhaps crucially, I see no problems with released rgdal 1.4-8 on R 4.0.0 and
PROJ 7.0.1 with GDAL 3.1.0RC2, or with devel rgdal trunk SVN rev. 966 and
PROJ 7.0.1 with GDAL 3.1.0RC2. The failing cases are with PROJ 7.0.0, and R
3.6.3. Further, I don't know whether that is running ASAN, valgrind, or
Thanks. I've been testing on master, but last built a month ago. Installing
RC2 now.
Roger
-
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev maili
Just for the record and in case the R authors are reading along, the
test suite for r-cran-rgdal (1.4-8-1) [0] & r-cran-sf (0.9-2+dfsg-1) [1]
fail with gdal (3.1.0~rc2+dfsg-1~exp1) from Debian experimental [2].
[0]
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/5203587/log.gz
Hi,
I have prepared a second release candidate.
The changes since RC1 are:
- (reason for this RC2) fix a regression of ./configure regarding linking some
dependencies
such as GEOS, on older systems that don't support the -E switch of sed
- typo fixes
- addition of a LICENSE file for gdal_rtd do
24 matches
Mail list logo