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
