Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/13/21 11:32 AM, Sebastian Ramacher wrote:
> On 2021-06-13 11:14:45 +0200, Sebastiaan Couwenberg wrote:
>> On 6/13/21 10:58 AM, Andreas Beckmann wrote:
>>> On 13/06/2021 06.45, Sebastiaan Couwenberg wrote:
>>>> On 6/12/21 10:23 PM, Sebastian Ramacher wrote:
>>>>> I have unblocked gdal.
>>>>
>>>> Thanks, libgdal (3.2.2-1) will need to be unblocked as well, it goes
>>>
>>> libgdal-grass ?
>>
>> Obviously, yes.
>>
>>>> hand in hand with gdal (3.2.2+dfsg-1). libgdal needs the same upstream
>>>> version of gdal to build successfully.
>>>>
>>>>> Please go ahead with an upload adding a gdal3-data binary package.
>>>>
>>>> That's much more invasive as suggested in #986975 as it will need to
>>>> pass NEW in addition to an unblock.
>>>
>>> And it does not really help, since it just uncovers that there are more
>>> dependencies on not co-installable libraries: libogdi3.2/libogdi4.1 due
>>> to plugins in unversioned paths. Theoretically fixable as well by moving
>>> the plugins to a versioned path. Not sure what would show up next.
>>>
>>>> #986975 just adds Breaks: libgdal20 to libgdal28 for smoother upgrades
>>>> from buster, that seems like a reasonable change.
>>>
>>> See attached patch. Especially for its very verbose changelog entry ;-)
>>
>> A build with the Breaks is running as we speak, if that resolves the
>> montiverdi case I'll upload it to unstable, unless you expect more changes.
>
> Please rename the binary package and follow the spirit of Policy 8.2 also with
> the data files of gdal.
I don't want to go that route. Adding the Breaks removed the need for
full-upgrade twice, so that's better than we had before. I don't see the
need for renaming gdal-data.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: