Re: GDAL transition
On 11/20/2013 11:58 PM, Johan Van de Wauw wrote:
> On Sat, Nov 16, 2013 at 1:22 PM, Francesco P. Lovergine
> <frankie@debian.org> wrote:
>>
>>
>> Well done! In a few I will be back from my major tasks and can follow
>> the other urgent transition, i.e. gdal which also requires an ok
>> from RMs because its general impacts on many rdeps.
>>
> Is the version on experimental the version you intend to upload to unstable?
It's close that what will likely be uploaded to unstable. The symbols
files still need to be updated for all architectures, but gdal cannot be
built on hurd-i386 due to a FTBFS of xerces-c. Fixing the xerces-c build
is required before the gdal symbols can be collected for all architectures.
> Is there anything useful we can still do to help this update?
You can test builds of GDALs reverse dependencies. Or help with the
xerces-c issue on hurd-i386.
> Do all depending packages just need to be rebuild without changes to
> the sourcecode?
This is what I expect. I've not rebuild all GDAL rdepends yet, but those
I've done where clean rebuilds without any required changes for GDAL 1.10.x.
> I'm actually thinking about ubuntu (and derived projects such as osgeo
> live dvd): their next release is a "LTS" release, so it would be nice
> if the new gdal could make it there. I could file a sync request from
> experimental but I only want to do that if it is the same version that
> the one which will go into sid.
I agree that having recent upstream versions of GDAL and friends is nice
to have for the next Ubuntu LTS, so the packages can just be synced from
Debian instead of requiring the use of the UbuntuGIS PPA for recent
versions.
Syncing packages from experimental I can't recommend. They are uploaded
there because they're not fit for unstable yet. Besides uploads to
experimental for symbol changes of C++ libraries, we're also staging
transitions there. Especially for an LTS release I recommend to wait for
packages to move from experimental to unstable before syncing.
> Johan
Kind Regards,
Bas
--
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)
Reply to: