Bug#986975: libgdal28: please add Breaks: libgdal20

Sebastiaan Couwenberg sebastic at xs4all.nl
Fri Apr 16 10:05:25 BST 2021


On 4/16/21 10:39 AM, Andreas Beckmann wrote:
> Hi Sebastiaan,
> 
> On 15/04/2021 07.34, Sebastiaan Couwenberg wrote:
>> This issue cannot be fixed in bullseye because gdal cannot be updated
>> via unstable.
> 
> Can you try to get this in via tpu?

>From the freeze policy:

"
 We very strongly prefer changes that can be done via unstable instead
 of testing-proposed-updates. If there are unrelated changes in
 unstable, we ask you to revert these changes instead of making an
 upload to testing-proposed-updates. Hence, and also because it may
 impact other packages in unstable that try to migrate to bullseye, it
 is recommended that, during the freeze, you do not upload to unstable
 any changes for which you do not intend to request an unblock.
"

As I'm not going to revert the changes in unstable for this issue, gdal
cannot be updated before the freeze. It could be fixed with a
stable-update after the release, but I doubt that's worth the effort as
upgrading the kept back packages after full-upgrade is sufficient. This
is something I had to do for other packages on some systems during the
distribution upgrade to buster as well.

> Apply to and upload the sid version first ...
> 
>> The release team is unlikely to unblock the package in unstable because
>> it also has changes for 3.2.2 which was uploaded to unstable by mistake.
>>
>> The issue cannot be reproduced when only gdal-bin and its dependencies
>> are installed. `apt full-upgrade` has no issues.
>>
>> When monteverdi is installed, after `apt upgrade && apt full-upgrade`
>> apt finds a solution when the kept back packages are explicitly
>> installed/upgraded.
>>
>> Shouldn't this issue be fixed in hdf5 since that causes the problem?
> 
> I can fix some of the hdf5 problems by adding some Breaks to libsz2
> (currently being tested). libsz2 is a dependency of libhdf5-103{,-1} and
> usually has a higher score than it. Adding a Breaks against libgdal20
> there too works only for a part of the cases since libgdal20 usually has
> a higher score (that scoring is sometimes a bit like magic), but in
> these cases libgdal28 would have a winning score. (But libsz2 seems to
> solve the cases where libgdal28 loses to libgdal20, so both are needed.)
> 
> The bigger hammer would be gcc-10-base ... I'll need to add some Breaks
> there for some difficult upgrade paths, but would like to keep that as
> minimal as possible.

monteverdi has a very low popcon, so this issue is unlikely to affect
many users. It doesn't seem pressing enough to fix in gdal.

Kind Regards,

Bas

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



More information about the Pkg-grass-devel mailing list