Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/13/21 11:12 AM, Sebastian Ramacher wrote:
> On 2021-06-13 10:58:19 +0200, 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 ?
>>
>>> 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.
>
> libogdi4.1 also needs an RC bug filed. It fails to meet a MUST
> requirement from 8.2 of the policy. Sorry, but I'm not interessted in
> papering over issuse that those packages introduce themselves by
> breaking co-installability and violating policy.
The ogdi build system is quite shit (it doesn't support DESTDIR for
example), changing the plugin pth is probably not a good idea. Moving
them to a separate package seems like the only right thing to do based
on the policy wording. But the package will have to pass NEW again,
which is also quite shit at this stage of the release.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: