Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-18 17:42:44 +0200, Sebastiaan Couwenberg wrote: > On 6/18/21 5:19 PM, Andreas Beckmann wrote: > > On 18/06/2021 09.50, Sebastiaan Couwenberg wrote: > >> I'm increasingly in favor of removing the Breaks from gdal-data, the > >> attached procedure works for me in buster chroot. > > > >> There is much less need for gdal-data breaking libgdal20 for us than > >> there is in the UbuntuGIS PPA use case. I'm not aware of any packages > >> that use gdal in the maintainer scripts that would be using the old gdal > >> on their removal. So there shouldn't be any actual expected breakage. > > > > Do you have some ideas what could break by installing gdal-data 3.x in > > buster? > > qgis crssync is a likely candidate, prior to PROJ 6 it relied more more > heavily on the projection data included in gdal. > > Other than that I don't know. You'd have to grep through the sources to > find the functions using those files, and then search through reverse > dependencies for use of those functions. > > > I.e. on a partial upgrade. (Could someone run autopkgtests in > > buster with the proposed gdal-data?) > > Many of the gdal rdeps don't have autopkgtests, and the most prominents > ones don't. > > >> This change is minimal, doesn't require NEW packages, nor introduces > >> divergence from upstream (as when the files would be moved to > >> u/s/gdal/ in libgdal28), hence it's my preferred solution. > > > > That's a bad upstream decision, but as you described them, they don't > > care about upgrade paths :-( > > PostGIS upstream are the ones who don't particular care about > distribution upgrades. GDAL upstream is actually quite good (and > responsible for the bulk of the work that went into PROJ 6). > > >> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the > >> changes from the debdiff to unstable. > > > > Sounds fine to me. > > If the RMs are onboard as well, then let's not waste any more time on > alternatives. It's a step in the right direction. So, yes, please go ahead. Cheers > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/18/21 5:19 PM, Andreas Beckmann wrote: > On 18/06/2021 09.50, Sebastiaan Couwenberg wrote: >> I'm increasingly in favor of removing the Breaks from gdal-data, the >> attached procedure works for me in buster chroot. > >> There is much less need for gdal-data breaking libgdal20 for us than >> there is in the UbuntuGIS PPA use case. I'm not aware of any packages >> that use gdal in the maintainer scripts that would be using the old gdal >> on their removal. So there shouldn't be any actual expected breakage. > > Do you have some ideas what could break by installing gdal-data 3.x in > buster? qgis crssync is a likely candidate, prior to PROJ 6 it relied more more heavily on the projection data included in gdal. Other than that I don't know. You'd have to grep through the sources to find the functions using those files, and then search through reverse dependencies for use of those functions. > I.e. on a partial upgrade. (Could someone run autopkgtests in > buster with the proposed gdal-data?) Many of the gdal rdeps don't have autopkgtests, and the most prominents ones don't. >> This change is minimal, doesn't require NEW packages, nor introduces >> divergence from upstream (as when the files would be moved to >> u/s/gdal/ in libgdal28), hence it's my preferred solution. > > That's a bad upstream decision, but as you described them, they don't > care about upgrade paths :-( PostGIS upstream are the ones who don't particular care about distribution upgrades. GDAL upstream is actually quite good (and responsible for the bulk of the work that went into PROJ 6). >> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the >> changes from the debdiff to unstable. > > Sounds fine to me. If the RMs are onboard as well, then let's not waste any more time on alternatives. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 18/06/2021 09.50, Sebastiaan Couwenberg wrote: I'm increasingly in favor of removing the Breaks from gdal-data, the attached procedure works for me in buster chroot. There is much less need for gdal-data breaking libgdal20 for us than there is in the UbuntuGIS PPA use case. I'm not aware of any packages that use gdal in the maintainer scripts that would be using the old gdal on their removal. So there shouldn't be any actual expected breakage. Do you have some ideas what could break by installing gdal-data 3.x in buster? I.e. on a partial upgrade. (Could someone run autopkgtests in buster with the proposed gdal-data?) If there are applications known to be broken, we could add versioned Breaks against them to the new gdal-data. The following files are removed: 2/usr/share/gdal/compdcs.csv |only 2/usr/share/gdal/coordinate_axis.csv |only 2/usr/share/gdal/datum_shift.csv |only 2/usr/share/gdal/ellipsoid.csv |only 2/usr/share/gdal/esri_Wisconsin_extra.wkt |only 2/usr/share/gdal/esri_epsg.wkt |only 2/usr/share/gdal/esri_extra.wkt|only 2/usr/share/gdal/gcs.csv |only 2/usr/share/gdal/gcs.override.csv |only 2/usr/share/gdal/gdal_datum.csv|only 2/usr/share/gdal/geoccs.csv|only 2/usr/share/gdal/pcs.csv |only 2/usr/share/gdal/pcs.override.csv |only 2/usr/share/gdal/prime_meridian.csv|only 2/usr/share/gdal/projop_wparm.csv |only 2/usr/share/gdal/unit_of_measure.csv |only 2/usr/share/gdal/vertcs.csv|only 2/usr/share/gdal/vertcs.override.csv |only these are modified: 3/usr/share/gdal/epsg.wkt |1 3/usr/share/gdal/gdalvrt.xsd | 150 +++ 3/usr/share/gdal/header.dxf| 106 -- 3/usr/share/gdal/nitf_spec.xml | 538 - 3/usr/share/gdal/nitf_spec.xsd |9 3/usr/share/gdal/ogrvrt.xsd|5 3/usr/share/gdal/osmconf.ini | 19 3/usr/share/gdal/pds4_template.xml | 14 3/usr/share/gdal/plscenesconf.json | 255 ++ 3/usr/share/gdal/ruian_vf_ob_v1.gfs|2 3/usr/share/gdal/ruian_vf_v1.gfs |2 3/usr/share/gdal/s57objectclasses.csv |6 3/usr/share/gdal/trailer.dxf | 382 + and these are new and should not cause any harm 3/usr/share/gdal/gdalmdiminfo_output.schema.json |only 3/usr/share/gdal/pdfcomposition.xsd|only 3/usr/share/gdal/template_tiles.mapml |only 3/usr/share/gdal/tms_LINZAntarticaMapTileGrid.json |only 3/usr/share/gdal/tms_MapML_APSTILE.json|only 3/usr/share/gdal/tms_MapML_CBMTILE.json|only 3/usr/share/gdal/tms_NZTM2000.json |only 3/usr/share/gdal/vicar.json|only 39 files changed, 1352 insertions(+), 137 deletions(-) This change is minimal, doesn't require NEW packages, nor introduces divergence from upstream (as when the files would be moved to u/s/gdal/ in libgdal28), hence it's my preferred solution. That's a bad upstream decision, but as you described them, they don't care about upgrade paths :-( If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the changes from the debdiff to unstable. Sounds fine to me. Andreas
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
Re: Sebastiaan Couwenberg
> Since the upgrade procedure documented in the release notes includes
> purging removed and obsolete packages, users are not expected to keep
> libgda20 around after the distribution upgrade.
To avoid exactly this problem, postgresql-common is maintaining a list
of PG versions that have clusters on the system:
/etc/apt/apt.conf.d/01autoremove-postgresql
APT
{
NeverAutoRemove
{
"^postgresql.*-11";
"^postgresql.*-13";
};
};
... so libgdal20 will not be autoremoved because
postgresql-11-postgis-2.5 is not autoremoved. The list is updated once
you `pg_dropcluster 11 main`.
> There is much less need for gdal-data breaking libgdal20 for us than
> there is in the UbuntuGIS PPA use case. I'm not aware of any packages
> that use gdal in the maintainer scripts that would be using the old gdal
> on their removal. So there shouldn't be any actual expected breakage.
I don't know the GIS world enough to be able to say what the data
files in gdal-data are good for, but my guess would be that for the
"read geometry data from an old postgresql-11 cluster", which is what
we need for pg_upgradecluster, they aren't relevant, and just making
libgdal20 co-installable is enough.
People shouldn't be expecting to be able to use the old postgis to do
complex data type (gdal?) or coordinate system (proj?) transformations
on a system that has already been upgraded to the new library versions
anyway.
> This change is minimal, doesn't require NEW packages, nor introduces
> divergence from upstream (as when the files would be moved to
> u/s/gdal/ in libgdal28), hence it's my preferred solution.
>
> If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
> changes from the debdiff to unstable.
Sounds good to me, thanks!
Christoph
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
Re: Andreas Beckmann > > modulo the problem I ran into. (I still have to retry it.) > > Didn't see this on my side. > Your --force-depends probably affected more than just libgdal20. Found the problem, I had not restarted postgresql-11 after the upgrade, so it was still linked against the old libc, but dlopening the various postgis libs failed as these want the new libc. After restarting, the geometry data is still there. > So co-installable libgdal20/libgdal28 simplifies postgis data migration > because postgresql-11+postgis from buster remains installed and accessible > along postgresql-13+postgis. Yes. Christoph
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/15/21 8:23 AM, Andreas Beckmann wrote: > On 15/06/2021 06.05, Sebastiaan Couwenberg wrote: >> From the many other packages I haven't seen other issues other than the >> partial upgrade with monteverdi which is fixed with Breaks/Replaces. >> >> I really need more concrete cases to justify changes to gdal that I >> don't like but will have to maintain. > > What about libmrpt-dev ? (log posted here yesterday) With hdf5 (1.10.6+repack-4) and ogdi-dfsg (4.1.0+ds-5) from unstable the full-upgrade still fails to find a solution. With the Breaks removed from gdal-data it works. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/14/21 1:49 PM, Sebastiaan Couwenberg wrote:
> On 6/14/21 1:30 PM, Andreas Beckmann wrote:
>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote:
>>> What actual problems do are solved by making them co-installable?
>>>
>>> So far the only actualy problem that has been identified is the need for
>>> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not
>>> present.
>>
>> apt currently fails to find an upgrade path for libmrpt-dev (logfile
>> attached, no bug filed, yet). The only solution I could find so far was
>> the big hammer: adding a Breaks against libopencv-core3.2 (or similar)
>> to gcc-10-base.
>> With a co-installable libgdal20/libgdal28 this is gone because the huge
>> dependency trees no longer conflict with each other.
>>
>> Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade
>> issues. So I can concentrate on fixing the remaining incomplete
>> (unversioned) python (2) removal bits. ;-)
>
> If co-installable libgdal is a must, then I'd rather drop gdal-data and
> move its content back to libgdal28 with an override for the
> big-usr-share lintian issue. That's how it was a long time ago:
>
>
> https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a
>
> I'm not in favor of either option, though.
>
> We can also drop the Breaks from gdal-data, and have libgdal20 be broken
> for the bits that use it. It will help with the dependency resolution.
I'm increasingly in favor of removing the Breaks from gdal-data, the
attached procedure works for me in buster chroot.
Note the requirements of hdf5 (1.10.6+repack-4), ogdi-dfsg (4.1.0+ds-5),
and gdal (3.2.2+dfsg-2). Both hdf5 and ogdi-dfsg packages are taken from
sid and made available for bullseye via a local repo. gdal only drops
the Breaks to not have libgdal20 removed when libgdal28 is installed
(via postgresql-13-postgis-3 dependencies), see the attached debdiff.
Since the upgrade procedure documented in the release notes includes
purging removed and obsolete packages, users are not expected to keep
libgda20 around after the distribution upgrade.
There is much less need for gdal-data breaking libgdal20 for us than
there is in the UbuntuGIS PPA use case. I'm not aware of any packages
that use gdal in the maintainer scripts that would be using the old gdal
on their removal. So there shouldn't be any actual expected breakage.
This change is minimal, doesn't require NEW packages, nor introduces
divergence from upstream (as when the files would be moved to
u/s/gdal/ in libgdal28), hence it's my preferred solution.
If there is no objection, I'll upload gdal (3.2.2+dfsg-2) with the
changes from the debdiff to unstable.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
# Have hdf5 (1.10.6+repack-4), ogdi-dfsg (4.1.0+ds-5), gdal (3.2.2+dfsg-2)
available for bullseye
apt install postgresql postgresql-11-postgis-2.5{,-scripts} sudo less
pg_ctlcluster 11 main start
sudo -u postgres createdb test
sudo -u postgres psql -vON_ERROR_STOP=1 test
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 17/06/2021 15.26, Christoph Berg wrote: Re: Andreas Beckmann * how do I get some tables using the postgis extension into the database to sudo -u postgres psql -vON_ERROR_STOP=1 < Thanks! Once gdal is fixed, I used my patched packages (will try to put them somewhere public tonight) pg_upgradecluster should work, It does ;-) (and it spews tons of errors (but does not fail) if I only install postgresql-13 but not postgresql-13-postgis-3) modulo the problem I ran into. (I still have to retry it.) Didn't see this on my side. Your --force-depends probably affected more than just libgdal20. So co-installable libgdal20/libgdal28 simplifies postgis data migration because postgresql-11+postgis from buster remains installed and accessible along postgresql-13+postgis. Andreas
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
Re: Andreas Beckmann
> So packaging wise this looks good. But I have no idea about the postgresql
> side:
> * how do I get some tables using the postgis extension into the database to
> start with? Is there a package in buster that "does that for me" by just
> installing it (postgis with --install-recommends pulls in
> postgresql-postgis, but does not populate a database)?
sudo -u postgres psql -vON_ERROR_STOP=1 < * how do I "verify" that? (SELECT foo FROM bar ...)
select * from test;
geom
01030001000500F03FF03FF03F0040004000400040F03FF03FF03F
> * how do I correctly migrate the database (with postgis stuff) from 11 to 13
As said in my mail: pg_dumpall, then dist-upgrade, and load the dump
again.
Once gdal is fixed, pg_upgradecluster should work, modulo the problem
I ran into. (I still have to retry it.)
> * how do I verify that it worked ?
Do that select again.
> There should be a real package postgresql-postgis, not a virtual one.
Yes, but in the general case of other PG extension packages which are
usually quite small, I'm reluctant to add yet another micro-package
just for the dependencies. Though maybe that's the way to go...
> PS: @Christoph: In piuparts I'm using this receipe to upgrade postgresql
> clusters after dist-upgrades - is this the correct approach?
>
> echo "Upgrading PostgreSQL Cluster from ${from} to ${to}"
> pg_dropcluster ${to} main --stop
> pg_upgradecluster -v ${to} ${from} main
> echo "Dropping old PostgreSQL ${from} Cluster"
> pg_dropcluster ${from} main
Yes. (Though pg_upgradecluster is bad at reporting errors during the
upgrade, so you'd have to check if all tables/data arrived manually.)
Christoph
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
OK, I tried it as well.
buster# apt-get install postgresql-11-postgis-2.5
# in a minimal chroot, pulls in postgresql-11
# I haven't done anything with postgres, so it should be essentially
empty (so only default users, tables, data exist (if any))
buster# apt-get dist-upgrade
# to bullseye with hdf5, gdal, ... patched for libgdal2[08]
co-installability.
bullseye# apt-get install postgresql-13-postgis-3
# this cannot be pulled in via dependencies :-(
bullseye# pg_lsclusters
Ver Cluster Port Status OwnerData directory Log file
11 main5432 online postgres /var/lib/postgresql/11/main
/var/log/postgresql/postgresql-11-main.log
13 main5433 online postgres /var/lib/postgresql/13/main
/var/log/postgresql/postgresql-13-main.log
bullseye# dpkg -l | grep postgis
ii postgresql-11-postgis-2.52.5.1+dfsg-1
amd64Geographic objects support for PostgreSQL 11
ii postgresql-13-postgis-3 3.1.1+dfsg-1
amd64Geographic objects support for PostgreSQL 13
ii postgresql-13-postgis-3-scripts 3.1.1+dfsg-1
all Geographic objects support for PostgreSQL 13 -- SQL scripts
So packaging wise this looks good. But I have no idea about the
postgresql side:
* how do I get some tables using the postgis extension into the database
to start with? Is there a package in buster that "does that for me" by
just installing it (postgis with --install-recommends pulls in
postgresql-postgis, but does not populate a database)?
* how do I "verify" that? (SELECT foo FROM bar ...)
* how do I correctly migrate the database (with postgis stuff) from 11 to 13
* how do I verify that it worked ?
There should be a real package postgresql-postgis, not a virtual one.
That would make upgrades easier if a package depends on
postgresql-postgis to get the new version installed. With the virtual
package the dependency is already satisfied by the old package as there
is no upgrade path between virtual packages (especially if they are
provided by different binary packages). And for obvious reasons, we
don't want to add Breaks the old providers.
(Installing postgis in buster with --install-recommends enabled does not
pull in postgresql-13-postgis-3 during dist-upgrade with
--install-recommends enabled.)
Andreas
PS: @Christoph: In piuparts I'm using this receipe to upgrade postgresql
clusters after dist-upgrades - is this the correct approach?
echo "Upgrading PostgreSQL Cluster from ${from} to ${to}"
pg_dropcluster ${to} main --stop
pg_upgradecluster -v ${to} ${from} main
echo "Dropping old PostgreSQL ${from} Cluster"
pg_dropcluster ${from} main
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
Re: Adrian Bunk > > FEHLER: XX000: konnte Bibliothek > > »/usr/lib/postgresql/11/lib/postgis-2.5.so« nicht laden: > > /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required > > by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1) > > > > So there seems to be some additional incompatibility in libsfcgal1 -> libc6. > >... > > It's already in the package dependencies: > > Package: libsfcgal1 > Version: 1.3.9-2 > Depends: ..., libc6 (>= 2.29),... > > This won't work unless you upgrade libc6 to the bullseye version. I think had dist-upgraded to sid at that point. Though I can repeat the test tomorrow to be sure. Christoph
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On Wed, Jun 16, 2021 at 06:15:45PM +0200, Christoph Berg wrote: >... > $ psql cb > psql (13.3 (Debian 13.3-1), Server 11.12 (Debian 11.12-0+deb10u1)) > > 17:38 cbe@cb =# select geom from country where geom is not null limit 1; > FEHLER: XX000: konnte Bibliothek »/usr/lib/postgresql/11/lib/postgis-2.5.so« > nicht laden: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found > (required by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1) > > So there seems to be some additional incompatibility in libsfcgal1 -> libc6. >... It's already in the package dependencies: Package: libsfcgal1 Version: 1.3.9-2 Depends: ..., libc6 (>= 2.29),... This won't work unless you upgrade libc6 to the bullseye version. > Christoph cu Adrian
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
Re: Sebastiaan Couwenberg
> Options for a working postgis database after distribution upgrade
> include recreating the databases by running your ETL process on the new
> cluster after upgrade, or using symlink hacks to workaround the
> version-in-extension-filename issue:
>
> http://blog.cleverelephant.ca/2016/08/postgis-upgrade.html
This is the infamous "symlink" hack that was occasionally needed in
the past, but I don't think it is necessary for this issue sind we are
talking about proper "CREATE EXTENSION postgis" installed, not the old
wild-west style with 1000 free-floating functions create in the
database.
> The hard upgrade procedure from the upstream docs may be an option too:
>
> http://postgis.net/docs/manual-3.1/postgis_administration.html#upgrading
>
> In my experience, recreating the database is the simplest solution.
Before I answer this, I gave upgrading buster with
postgresql-11-postgis-2.5{,-scripts} to sid with postgresql-13-postgis-3
a try. As expected, libgdal20 and postgresql-11-postgis-2.5 were
removed during the process, and trying to access geometry data in the
old postgresql-11 database fails:
# select geom from country where geom is not null limit 1;
FEHLER: 58P01: konnte nicht auf Datei »$libdir/postgis-2.5« zugreifen: Datei
oder Verzeichnis nicht gefunden
To see what would happen if we made libgdal20 and libgdal28
co-installable, I force-installed the old packages:
$ sudo dpkg -i --force-depends
/var/cache/apt/archives/libgdal20_2.4.0+dfsg-1+b1_amd64.deb
/var/cache/apt/archives/postgresql-11-postgis-2.5_2.5.1+dfsg-1_amd64.deb
[...]
Entpacken von postgresql-11-postgis-2.5 (2.5.1+dfsg-1) ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von libgdal20:
gdal-data (3.2.2+dfsg-1) beschädigt libgdal20 (<< 2.5.0~) und ist installiert.
Zu konfigurierende Version von libgdal20 auf dem System ist 2.4.0+dfsg-1+b1.
dpkg: Fehler beim Bearbeiten des Paketes libgdal20 (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: postgresql-11-postgis-2.5: Abhängigkeitsprobleme, wird aber trotzdem wie
gefordert konfiguriert:
postgresql-11-postgis-2.5 hängt ab von libgdal20 (>= 2.0.1); aber:
Paket libgdal20 ist noch nicht konfiguriert.
postgresql-11-postgis-2.5 (2.5.1+dfsg-1) wird eingerichtet ...
Trigger für libc-bin (2.31-12) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
libgdal20
Ignoring these errors I proceeded to try reading the old geometry data:
$ psql cb
psql (13.3 (Debian 13.3-1), Server 11.12 (Debian 11.12-0+deb10u1))
17:38 cbe@cb =# select geom from country where geom is not null limit 1;
FEHLER: XX000: konnte Bibliothek »/usr/lib/postgresql/11/lib/postgis-2.5.so«
nicht laden: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found
(required by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1)
So there seems to be some additional incompatibility in libsfcgal1 -> libc6.
At that point, I think fixing that isn't feasible, and we should
instead put proper upgrade instructions into the release notes. My
plan would be the following:
sudo -u postgres pg_dumpall -f postgres11.dump
... do the upgrade
sudo apt install postgresql-13-postgis-3
#sudo pg_createcluster 13 main --start # automatically created by postgresql-13
sudo -u postgres psql -p 5433 -Xf postgres11.dump
# select geom from country where geom is not null limit 1;
geom
──
010620E6100100010
Would such instructions in the release notes be an acceptable
resolution for this bug? We can additionally point to the "hard"
upgrade instruction mentioned above for people still using the
non-extension installation methode.
> > If I am not mistaken, Andreas proposed in another thread to introduce a
> > postgis-2.5-built-against-postgresql-13 package to help with the
> > upgrades. Would this be a viable option?
>
> No. I'm not going to maintain multiple versions of postgis.
postgis-2.5-built-against-postgresql-13 wouldn't help since we need to
get the data out of the old postgresql-11 first.
> It will be one less package I have to maintain in Debian, I can just
> chuck in my personal repo and not bother any further.
Please don't, you are doing useful work here. I appreciate your
efforts.
Christoph
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/15/21 3:55 PM, Sebastian Ramacher wrote: > On 2021-06-15 13:18:23, Sebastiaan Couwenberg wrote: >> On 6/15/21 1:00 PM, Sebastian Ramacher wrote: >>> If neither you as maintainer nor upstream care about upgrade without >>> data loss, I don't think postgis is suitable to be included in a stable >>> release. Best option moving forward is to get postgis and its reverse >>> dependencies removed from bullseye. >> >> Removing postgis during distribution upgrade does not cause data loss. >> Don't try to make this issue bigger than it is. > > Again: how are users supposed to upgrade their postgis installation > while retaining their data? So far I only found upstream's instructions > which you told me are "shit". There are also not instructions or hints > included in the release notes for bullseye. Upgrading postgis is not supported and has never been. Stop trying to make that happen without upstream commitment. It may be news to you or some users of postgis, but it's not a new thing. Don't expect me to be willing to spend time on an ancient issue. Options for a working postgis database after distribution upgrade include recreating the databases by running your ETL process on the new cluster after upgrade, or using symlink hacks to workaround the version-in-extension-filename issue: http://blog.cleverelephant.ca/2016/08/postgis-upgrade.html The hard upgrade procedure from the upstream docs may be an option too: http://postgis.net/docs/manual-3.1/postgis_administration.html#upgrading In my experience, recreating the database is the simplest solution. > If I am not mistaken, Andreas proposed in another thread to introduce a > postgis-2.5-built-against-postgresql-13 package to help with the > upgrades. Would this be a viable option? No. I'm not going to maintain multiple versions of postgis. > We're trying to find solutions here to help user's with their postgis > upgrades. After all, this discussion started after a user experienced > issues. If we cannot provide users of the postgis package with an > upgrade path, then yes, this is a grave bug. It needs to be dealt with. > "Don't bother" and "it's shit" is not good enough. Stop bothering with postgis. It's not worth our time, not yours, and not mine. We don't get paid enough for that. > One of the judgment calls we as maintainers have to make is whether a > piece of software is suitable for a Debian stable release and if we can > support upgrades from one stable to the next one. The information that I > got so far from you, is that postgis does not care about the second > part. I'd love to be convinced otherwise. Not having postgis in stable will hurt users more than the terrible upgrade experience it has always had. It will be one less package I have to maintain in Debian, I can just chuck in my personal repo and not bother any further. Perhaps I should do that with all the GIS packages, leave it to someone else to deal with all the bullshit in Debian. With every interaction about this postgis issue, I lose ever more motivation to work on any of the other issues as well. In case you hadn't noticed, there is a distinct lack of other people working on these packages. You are doing its users a disservice on your path of alienating its only active contributor. With postgis you may find Myon willing to work on it, but with the other packages like gdal you don't have that luxury. Stop hammering on this postgis issue, you won't get me to work on it. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-15 13:18:23, Sebastiaan Couwenberg wrote: > On 6/15/21 1:00 PM, Sebastian Ramacher wrote: > > If neither you as maintainer nor upstream care about upgrade without > > data loss, I don't think postgis is suitable to be included in a stable > > release. Best option moving forward is to get postgis and its reverse > > dependencies removed from bullseye. > > Removing postgis during distribution upgrade does not cause data loss. > Don't try to make this issue bigger than it is. Again: how are users supposed to upgrade their postgis installation while retaining their data? So far I only found upstream's instructions which you told me are "shit". There are also not instructions or hints included in the release notes for bullseye. If I am not mistaken, Andreas proposed in another thread to introduce a postgis-2.5-built-against-postgresql-13 package to help with the upgrades. Would this be a viable option? We're trying to find solutions here to help user's with their postgis upgrades. After all, this discussion started after a user experienced issues. If we cannot provide users of the postgis package with an upgrade path, then yes, this is a grave bug. It needs to be dealt with. "Don't bother" and "it's shit" is not good enough. One of the judgment calls we as maintainers have to make is whether a piece of software is suitable for a Debian stable release and if we can support upgrades from one stable to the next one. The information that I got so far from you, is that postgis does not care about the second part. I'd love to be convinced otherwise. Cheers -- Sebastian Ramacher
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/15/21 1:00 PM, Sebastian Ramacher wrote: > If neither you as maintainer nor upstream care about upgrade without > data loss, I don't think postgis is suitable to be included in a stable > release. Best option moving forward is to get postgis and its reverse > dependencies removed from bullseye. Removing postgis during distribution upgrade does not cause data loss. Don't try to make this issue bigger than it is. As an RM you should know that stable releases include a lot more packages which have issues more severe than this one for postgis. Your attempt to force my hand is with threats of removal from stable are not appreciated. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-15 06:05:28, Sebastiaan Couwenberg wrote: > On 6/14/21 9:55 PM, Sebastian Ramacher wrote: > > On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote: > >> On 6/14/21 1:30 PM, Andreas Beckmann wrote: > >>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote: > What actual problems do are solved by making them co-installable? > > So far the only actualy problem that has been identified is the need for > `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not > present. > >>> > >>> apt currently fails to find an upgrade path for libmrpt-dev (logfile > >>> attached, no bug filed, yet). The only solution I could find so far was > >>> the big hammer: adding a Breaks against libopencv-core3.2 (or similar) > >>> to gcc-10-base. > >>> With a co-installable libgdal20/libgdal28 this is gone because the huge > >>> dependency trees no longer conflict with each other. > >>> > >>> Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade > >>> issues. So I can concentrate on fixing the remaining incomplete > >>> (unversioned) python (2) removal bits. ;-) > >> > >> If co-installable libgdal is a must, then I'd rather drop gdal-data and > >> move its content back to libgdal28 with an override for the > >> big-usr-share lintian issue. That's how it was a long time ago: > >> > >> > >> https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a > >> > >> I'm not in favor of either option, though. > > > > Not having libgdal20 and libgdal28 co-installable makes it unneccessarly > > hard to upgrade all of libgdal's reverse dependencies that also bumped > > SONAMEs. That set of packages includes at least opencv, pdal, qgis, > > vtk7, otb, mapnik, openscenegraph and gazebo. And then there are > > probably even more that are reverse dependencies of those packages which > > bumped SONAME. So this issues affects many many packages and is not > > only related to postgis. > > Again, postgis database upgrades have never been supported. You're > wasting your time on that. > > >From the many other packages I haven't seen other issues other than the > partial upgrade with monteverdi which is fixed with Breaks/Replaces. > > I really need more concrete cases to justify changes to gdal that I > don't like but will have to maintain. If neither you as maintainer nor upstream care about upgrade without data loss, I don't think postgis is suitable to be included in a stable release. Best option moving forward is to get postgis and its reverse dependencies removed from bullseye. Cheers > > > In any case, all these options seem rather unsatisfying and fragile. > > Manually building specific postgis versions against specific postgresql > > versions seems like a recipe for desaster. If one screws up any of the > > steps, one can only hope for a backup and needs to start over. libgdal's > > co-installablity issue makes that even more brittle then necessary if > > not impossible. > > As said before, upgrade support of postgis is shit. Upstream does not > take that use case very seriously, although some of the postgis > developers are as unhappy with that as we are. > > I don't have the time, energy, nor knowledge required to fix this > upstream. So I've just been recreating my postgis databases in the new > cluster after every distribution upgrade. > > > To be honest, from a package in Debian I would expect more. This is a > > frustrating upgrade experience. And even if we cannot fix postgis > > upgrades in time, having libgdal20 and libgdal28 not co-installable, > > makes it only more painful for our users. So I'd say, yes, libgdal20 and > > libgdal28 co-installablity is a must. > > > >> We can also drop the Breaks from gdal-data, and have libgdal20 be broken > >> for the bits that use it. It will help with the dependency resolution. > > > > If a non-function libgdal20 would mean that even if if installed, it's > > completely useless for the cases above, then no, that's not an option. > > The scope of how broken libgdal20 is without all of the data files it > expects is difficult to determine. The data files are considered a hard > dependency, hence the Breaks on libgdal20 due to the changes for PROJ 6. > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -- Sebastian Ramacher
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/15/21 8:23 AM, Andreas Beckmann wrote: > On 15/06/2021 06.05, Sebastiaan Couwenberg wrote: >> From the many other packages I haven't seen other issues other than the >> partial upgrade with monteverdi which is fixed with Breaks/Replaces. >> >> I really need more concrete cases to justify changes to gdal that I >> don't like but will have to maintain. > > What about libmrpt-dev ? (log posted here yesterday) The root cause of that seems to be hdf5, isn't that fixed with the transitional package changes from #988722? Let's get hdf5 fixed in bullseye first before moving up the stack. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 15/06/2021 06.05, Sebastiaan Couwenberg wrote: From the many other packages I haven't seen other issues other than the partial upgrade with monteverdi which is fixed with Breaks/Replaces. I really need more concrete cases to justify changes to gdal that I don't like but will have to maintain. What about libmrpt-dev ? (log posted here yesterday) Andreas
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/14/21 9:55 PM, Sebastian Ramacher wrote: > On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote: >> On 6/14/21 1:30 PM, Andreas Beckmann wrote: >>> On 14/06/2021 10.06, Sebastiaan Couwenberg wrote: What actual problems do are solved by making them co-installable? So far the only actualy problem that has been identified is the need for `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not present. >>> >>> apt currently fails to find an upgrade path for libmrpt-dev (logfile >>> attached, no bug filed, yet). The only solution I could find so far was >>> the big hammer: adding a Breaks against libopencv-core3.2 (or similar) >>> to gcc-10-base. >>> With a co-installable libgdal20/libgdal28 this is gone because the huge >>> dependency trees no longer conflict with each other. >>> >>> Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade >>> issues. So I can concentrate on fixing the remaining incomplete >>> (unversioned) python (2) removal bits. ;-) >> >> If co-installable libgdal is a must, then I'd rather drop gdal-data and >> move its content back to libgdal28 with an override for the >> big-usr-share lintian issue. That's how it was a long time ago: >> >> >> https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a >> >> I'm not in favor of either option, though. > > Not having libgdal20 and libgdal28 co-installable makes it unneccessarly > hard to upgrade all of libgdal's reverse dependencies that also bumped > SONAMEs. That set of packages includes at least opencv, pdal, qgis, > vtk7, otb, mapnik, openscenegraph and gazebo. And then there are > probably even more that are reverse dependencies of those packages which > bumped SONAME. So this issues affects many many packages and is not > only related to postgis. Again, postgis database upgrades have never been supported. You're wasting your time on that. >From the many other packages I haven't seen other issues other than the partial upgrade with monteverdi which is fixed with Breaks/Replaces. I really need more concrete cases to justify changes to gdal that I don't like but will have to maintain. > In any case, all these options seem rather unsatisfying and fragile. > Manually building specific postgis versions against specific postgresql > versions seems like a recipe for desaster. If one screws up any of the > steps, one can only hope for a backup and needs to start over. libgdal's > co-installablity issue makes that even more brittle then necessary if > not impossible. As said before, upgrade support of postgis is shit. Upstream does not take that use case very seriously, although some of the postgis developers are as unhappy with that as we are. I don't have the time, energy, nor knowledge required to fix this upstream. So I've just been recreating my postgis databases in the new cluster after every distribution upgrade. > To be honest, from a package in Debian I would expect more. This is a > frustrating upgrade experience. And even if we cannot fix postgis > upgrades in time, having libgdal20 and libgdal28 not co-installable, > makes it only more painful for our users. So I'd say, yes, libgdal20 and > libgdal28 co-installablity is a must. > >> We can also drop the Breaks from gdal-data, and have libgdal20 be broken >> for the bits that use it. It will help with the dependency resolution. > > If a non-function libgdal20 would mean that even if if installed, it's > completely useless for the cases above, then no, that's not an option. The scope of how broken libgdal20 is without all of the data files it expects is difficult to determine. The data files are considered a hard dependency, hence the Breaks on libgdal20 due to the changes for PROJ 6. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-14 13:49:47 +0200, Sebastiaan Couwenberg wrote: > On 6/14/21 1:30 PM, Andreas Beckmann wrote: > > On 14/06/2021 10.06, Sebastiaan Couwenberg wrote: > >> What actual problems do are solved by making them co-installable? > >> > >> So far the only actualy problem that has been identified is the need for > >> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not > >> present. > > > > apt currently fails to find an upgrade path for libmrpt-dev (logfile > > attached, no bug filed, yet). The only solution I could find so far was > > the big hammer: adding a Breaks against libopencv-core3.2 (or similar) > > to gcc-10-base. > > With a co-installable libgdal20/libgdal28 this is gone because the huge > > dependency trees no longer conflict with each other. > > > > Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade > > issues. So I can concentrate on fixing the remaining incomplete > > (unversioned) python (2) removal bits. ;-) > > If co-installable libgdal is a must, then I'd rather drop gdal-data and > move its content back to libgdal28 with an override for the > big-usr-share lintian issue. That's how it was a long time ago: > > > https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a > > I'm not in favor of either option, though. Not having libgdal20 and libgdal28 co-installable makes it unneccessarly hard to upgrade all of libgdal's reverse dependencies that also bumped SONAMEs. That set of packages includes at least opencv, pdal, qgis, vtk7, otb, mapnik, openscenegraph and gazebo. And then there are probably even more that are reverse dependencies of those packages which bumped SONAME. So this issues affects many many packages and is not only related to postgis. But let's come back to postgis. I tried to look into upgrades and what users are expected to do here. Upstream's documentation on this topic can be found at https://postgis.net/workshops/postgis-intro/upgrades.html. So, what I gather from that is that one possible way to upgrade is: * Mark postgresql-11-postgis-2.5 as hold to ensure it's not removed. * Upgrade enough packages so that one gets the postgresql 13 development packages and postgresql-13 installed. * Manually build postgis 2.5.x against postgresql 13 and install it. * pg_upgradecluster * Finish the buster -> bullseye upgrade * Once postgresql-13-postgis-3 is installed, upgrade the postgis extension. I tried that starting from a minimal chroot only having postgis and postgresql installed, but was unable to end up with a set of packages which allows me to build postgis 2.5 against postgresql 13 without getting postgresql-11-postgis-2.5 removed first. And even if it worked, one would have to rebuild postgis 2.5.x at some point against libgdal28 to finish the upgrade. Next option: * pg_dumpall * Upgrade to bullseye * Build postgis 2.5.x against postgresql 13 and install the extensions. * pg_restore * Upgrade the postgis extension. This could work, I guess. But I didn't try it. Or, alternatively, first manually build postgis 3.1.x in buster: * Build postgis 3.1.x against postgresql 11 and install the extension * Upgrade the postgis extension. * Upgrade buster to bullseye * pg_upgradecluster Before running pg_upgradecluster one would probably need to rebuild postgis 3.1.x against postgresql 11 again because of libgdal28. Are there any other options? In any case, all these options seem rather unsatisfying and fragile. Manually building specific postgis versions against specific postgresql versions seems like a recipe for desaster. If one screws up any of the steps, one can only hope for a backup and needs to start over. libgdal's co-installablity issue makes that even more brittle then necessary if not impossible. To be honest, from a package in Debian I would expect more. This is a frustrating upgrade experience. And even if we cannot fix postgis upgrades in time, having libgdal20 and libgdal28 not co-installable, makes it only more painful for our users. So I'd say, yes, libgdal20 and libgdal28 co-installablity is a must. > We can also drop the Breaks from gdal-data, and have libgdal20 be broken > for the bits that use it. It will help with the dependency resolution. If a non-function libgdal20 would mean that even if if installed, it's completely useless for the cases above, then no, that's not an option. Cheers -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/14/21 1:30 PM, Andreas Beckmann wrote: > On 14/06/2021 10.06, Sebastiaan Couwenberg wrote: >> What actual problems do are solved by making them co-installable? >> >> So far the only actualy problem that has been identified is the need for >> `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not >> present. > > apt currently fails to find an upgrade path for libmrpt-dev (logfile > attached, no bug filed, yet). The only solution I could find so far was > the big hammer: adding a Breaks against libopencv-core3.2 (or similar) > to gcc-10-base. > With a co-installable libgdal20/libgdal28 this is gone because the huge > dependency trees no longer conflict with each other. > > Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade > issues. So I can concentrate on fixing the remaining incomplete > (unversioned) python (2) removal bits. ;-) If co-installable libgdal is a must, then I'd rather drop gdal-data and move its content back to libgdal28 with an override for the big-usr-share lintian issue. That's how it was a long time ago: https://salsa.debian.org/debian-gis-team/gdal/-/commit/140ab452687b2a6d92f3b760379fbbd81f80794a I'm not in favor of either option, though. We can also drop the Breaks from gdal-data, and have libgdal20 be broken for the bits that use it. It will help with the dependency resolution. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 14/06/2021 10.06, Sebastiaan Couwenberg wrote: What actual problems do are solved by making them co-installable? So far the only actualy problem that has been identified is the need for `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not present. apt currently fails to find an upgrade path for libmrpt-dev (logfile attached, no bug filed, yet). The only solution I could find so far was the big hammer: adding a Breaks against libopencv-core3.2 (or similar) to gcc-10-base. With a co-installable libgdal20/libgdal28 this is gone because the huge dependency trees no longer conflict with each other. Co-installable libgdal20/28 solves a lot of buster->bullseye upgrade issues. So I can concentrate on fixing the remaining incomplete (unversioned) python (2) removal bits. ;-) Andreas libmrpt-dev.1.norm.log.gz Description: application/gzip
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/14/21 9:29 AM, Andreas Beckmann wrote: > On 13/06/2021 23.44, Sebastian Ramacher wrote: >> On 2021-06-13 23:35:40 +0200, Andreas Beckmann wrote: >>> On 13/06/2021 22.44, Sebastian Ramacher wrote: My goal is to make libgdal20 and libgdal28 co-installable. Adding those Breaks is not enough and is step into the wrong direction. >>> >>> Thanks for making that clear. I'll think again about libogdi ... >> >> libogdi4.1 was partially fixed. It only needs the Breaks+Replaces >> removed. See 989795 > > I did some quick tests with the B+R removed, hdf5 patched to build the > transitional packages and gdal patched to produce gdal3-data: we have > finally achieved libgdal20/libgdal28 co-installability ;-) That's nice, but I don't want to maintain a version specific gdal-data package. postgis by itself is not interesting, its only contains commandline tools. postgresql-11-postgis-2.5 is the package which contains the postgresql extension. That (also) get removed during the `apt upgrade` from buster to bullseye. I don't particularly care about having libgdal20 & libgdal28 co-installable for postgis datavase upgrades with pg_upgradecluster. That has never been supported. What actual problems do are solved by making them co-installable? So far the only actualy problem that has been identified is the need for `apt full-upgrade` twice when the Breaks/Replaces on libgdal20 is not present. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 13/06/2021 23.44, Sebastian Ramacher wrote: On 2021-06-13 23:35:40 +0200, Andreas Beckmann wrote: On 13/06/2021 22.44, Sebastian Ramacher wrote: My goal is to make libgdal20 and libgdal28 co-installable. Adding those Breaks is not enough and is step into the wrong direction. Thanks for making that clear. I'll think again about libogdi ... libogdi4.1 was partially fixed. It only needs the Breaks+Replaces removed. See 989795 I did some quick tests with the B+R removed, hdf5 patched to build the transitional packages and gdal patched to produce gdal3-data: we have finally achieved libgdal20/libgdal28 co-installability ;-) More tests ongoing. This is how apt resolves the postgis upgrade - nothing has to be removed any more: Starting 2 pkgProblemResolver with broken count: 0 Done The following packages were automatically installed and are no longer required: gdal-data libarmadillo9 libboost-atomic1.67.0 libboost-chrono1.67.0 libboost-date-time1.67.0 libboost-filesystem1.67.0 libboost-program-options1.67.0 libboost-serialization1.67.0 libboost-serialization1.74.0 libboost-system1.67.0 libboost-test1.67.0 libboost-thread1.67.0 libboost-timer1.67.0 libcgal13 libdap25 libdapserver7v5 libgdal20 libgeos-3.7.1 libgeotiff2 libgmpxx4ldbl libhdf5-103 libhdf5-fortran-102 libhdf5-hl-fortran-100 libicu63 libjson-c3 libkmlconvenience1 libkmlregionator1 libkmlxsd1 liblwgeom-2.5-0 libmpfr6 libnetcdf13 libogdi3.2 libpoppler82 libpopt0 libproj13 libqhull7 libsfcgal1 Use 'sudo apt autoremove' to remove them. The following NEW packages will be installed: gcc-10-base gdal3-data libaom0 libapt-pkg6.0 libarmadillo10 libboost-serialization1.74.0 libbrotli1 libcfitsio9 libcrypt1 libdap27 libdav1d4 libde265-0 libdeflate0 libffi7 libgcc-s1 libgdal28 libgeos-3.9.0 libgeotiff5 libhdf5-103-1 libhdf5-fortran-102 libhdf5-hl-100 libhdf5-hl-fortran-100 libheif1 libhogweed6 libicu67 libjson-c5 libnetcdf18 libnettle8 libnsl2 libnuma1 libogdi4.1 libpcre2-8-0 libpoppler102 libproj19 libqhull8.0 librttopo1 libtirpc-common libtirpc3 libx265-192 libxxhash0 logsave lsb-base The following packages will be upgraded: apt base-files base-passwd bash bsdutils coreutils dash debconf debian-archive-keyring debianutils diffutils dpkg e2fsprogs fdisk findutils fontconfig-config fonts-dejavu-core gdal-data gpgv grep gzip hostname init-system-helpers libacl1 libaec0 libarpack2 libattr1 libaudit-common libaudit1 libblas3 libblkid1 libbz2-1.0 libc-bin libc6 libcap-ng0 libcharls2 libcom-err2 libcurl3-gnutls libdapclient6v5 libdapserver7v5 libdb5.3 libdebconfclient0 libepsilon1 libexpat1 libext2fs2 libfdisk1 libfontconfig1 libfreetype6 libfreexl1 libfyba0 libgcrypt20 libgeos-c1v5 libgfortran5 libgif7 libgmp10 libgmpxx4ldbl libgnutls30 libgpg-error0 libgssapi-krb5-2 libhdf4-0-alt libhdf5-103 libidn2-0 libjpeg62-turbo libk5crypto3 libkeyutils1 libkmlbase1 libkmlconvenience1 libkmldom1 libkmlengine1 libkmlregionator1 libkmlxsd1 libkrb5-3 libkrb5support0 liblapack3 liblcms2-2 libldap-2.4-2 libldap-common libltdl7 liblz4-1 liblzma5 libmariadb3 libmount1 libmpfr6 libncursesw6 libnghttp2-14 libnspr4 libnss3 libodbc1 libopenjp2-7 libp11-kit0 libpam-modules libpam-modules-bin libpam-runtime libpam0g libpcre3 libpng16-16 libpopt0 libpq5 libpsl5 libquadmath0 librtmp1 libsasl2-2 libsasl2-modules-db libseccomp2 libselinux1 libsemanage-common libsemanage1 libsepol1 libsfcgal1 libsmartcols1 libspatialite7 libsqlite3-0 libss2 libssh2-1 libssl1.1 libstdc++6 libsuperlu5 libsystemd0 libsz2 libtasn1-6 libtiff5 libtinfo6 libudev1 libunistring2 liburiparser1 libuuid1 libxerces-c3.2 libxml2 libzstd1 login mariadb-common mawk mount mysql-common ncurses-base ncurses-bin odbcinst odbcinst1debian2 passwd perl-base postgis proj-data sensible-utils sysvinit-utils tar ucf util-linux zlib1g 148 upgraded, 42 newly installed, 0 to remove and 0 not upgraded. Andreas
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-13 23:35:40 +0200, Andreas Beckmann wrote: > On 13/06/2021 22.44, Sebastian Ramacher wrote: > > My goal is to make libgdal20 and libgdal28 co-installable. Adding those > > Breaks is not enough and is step into the wrong direction. > > Thanks for making that clear. I'll think again about libogdi ... libogdi4.1 was partially fixed. It only needs the Breaks+Replaces removed. See 989795 Cheers > @Seb: could you upload the gdal3-data patch to experimental to get it > through NEW? > > Andreas > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 13/06/2021 22.44, Sebastian Ramacher wrote: My goal is to make libgdal20 and libgdal28 co-installable. Adding those Breaks is not enough and is step into the wrong direction. Thanks for making that clear. I'll think again about libogdi ... @Seb: could you upload the gdal3-data patch to experimental to get it through NEW? Andreas
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-13 17:57:46 +0200, Sebastiaan Couwenberg wrote: > 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. My goal is to make libgdal20 and libgdal28 co-installable. Adding those Breaks is not enough and is step into the wrong direction. Cheers > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -- Sebastian Ramacher signature.asc Description: PGP signature
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
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-13 11:30:47 +0200, Sebastiaan Couwenberg wrote: > 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. Well, that does not speak for the quality of ogdi-dfsg. If the build system is already that bad, is the C code of the same quality? In any case, a bug in an upstream build system does not excempt the package from following the policy for shared libraries. Cheers > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
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. Cheers > > > We may need to add this Breaks in some more packages since in rare cases > > old libgdal20 scores higher than libgdal28. But most cases are already > > covered with libgdal28. > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -- Sebastian Ramacher signature.asc Description: PGP signature
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
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
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. > We may need to add this Breaks in some more packages since in rare cases > old libgdal20 scores higher than libgdal28. But most cases are already > covered with libgdal28. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
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.
Best
Sebastian
>
> > #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 ;-)
>
> We may need to add this Breaks in some more packages since in rare cases old
> libgdal20 scores higher than libgdal28. But most cases are already covered
> with libgdal28.
>
> Andreas
> diff -Nru gdal-3.2.2+dfsg/debian/changelog gdal-3.2.2+dfsg/debian/changelog
> --- gdal-3.2.2+dfsg/debian/changelog 2021-03-10 15:12:55.0 +0100
> +++ gdal-3.2.2+dfsg/debian/changelog 2021-06-11 21:31:32.0 +0200
> @@ -1,3 +1,14 @@
> +gdal (3.2.2+dfsg-2) UNRELEASED; urgency=medium
> +
> + * libgdal28: Add Breaks: libgdal20 for smoother upgrades from buster. The
> +gdal libraries from buster and bullseye are not co-installable due to
> +incompatible gdal-data changes and dependencies on several not
> +co-installable libraries. The explicit Breaks helps apt finding the
> +correct solution (removal of libgdal20) which is sometimes hard to deduce
> +over long indirect dependency trees. (Closes: #986975)
> +
> + -- Andreas Beckmann Fri, 11 Jun 2021 21:31:32 +0200
> +
> gdal (3.2.2+dfsg-1) unstable; urgency=medium
>
>* New upstream release.
> diff -Nru gdal-3.2.2+dfsg/debian/control gdal-3.2.2+dfsg/debian/control
> --- gdal-3.2.2+dfsg/debian/control2021-03-10 15:06:40.0 +0100
> +++ gdal-3.2.2+dfsg/debian/control2021-06-11 21:31:27.0 +0200
> @@ -72,7 +72,7 @@
> ${shlibs:Depends},
> ${misc:Depends}
> Recommends: proj-bin
> -Breaks: libgdal1h (<< 2.0)
> +Breaks: libgdal1h (<< 2.0), libgdal20
> Description: Geospatial Data Abstraction Library
> GDAL is a translator library for raster geospatial data formats.
> As a library, it presents a single abstract data model to the
--
Sebastian Ramacher
signature.asc
Description: PGP signature
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
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.
#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 ;-)
We may need to add this Breaks in some more packages since in rare cases
old libgdal20 scores higher than libgdal28. But most cases are already
covered with libgdal28.
Andreas
diff -Nru gdal-3.2.2+dfsg/debian/changelog gdal-3.2.2+dfsg/debian/changelog
--- gdal-3.2.2+dfsg/debian/changelog 2021-03-10 15:12:55.0 +0100
+++ gdal-3.2.2+dfsg/debian/changelog 2021-06-11 21:31:32.0 +0200
@@ -1,3 +1,14 @@
+gdal (3.2.2+dfsg-2) UNRELEASED; urgency=medium
+
+ * libgdal28: Add Breaks: libgdal20 for smoother upgrades from buster. The
+gdal libraries from buster and bullseye are not co-installable due to
+incompatible gdal-data changes and dependencies on several not
+co-installable libraries. The explicit Breaks helps apt finding the
+correct solution (removal of libgdal20) which is sometimes hard to deduce
+over long indirect dependency trees. (Closes: #986975)
+
+ -- Andreas Beckmann Fri, 11 Jun 2021 21:31:32 +0200
+
gdal (3.2.2+dfsg-1) unstable; urgency=medium
* New upstream release.
diff -Nru gdal-3.2.2+dfsg/debian/control gdal-3.2.2+dfsg/debian/control
--- gdal-3.2.2+dfsg/debian/control 2021-03-10 15:06:40.0 +0100
+++ gdal-3.2.2+dfsg/debian/control 2021-06-11 21:31:27.0 +0200
@@ -72,7 +72,7 @@
${shlibs:Depends},
${misc:Depends}
Recommends: proj-bin
-Breaks: libgdal1h (<< 2.0)
+Breaks: libgdal1h (<< 2.0), libgdal20
Description: Geospatial Data Abstraction Library
GDAL is a translator library for raster geospatial data formats.
As a library, it presents a single abstract data model to the
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
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 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. #986975 just adds Breaks: libgdal20 to libgdal28 for smoother upgrades from buster, that seems like a reasonable change. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-11 21:21:09 +0200, Sebastiaan Couwenberg wrote: > On 6/11/21 8:49 PM, Sebastian Ramacher wrote: > > On 2021-06-09 12:41:29 +0200, Sebastiaan Couwenberg wrote: > >> On 6/9/21 12:11 PM, Andreas Beckmann wrote: > >>> On 08/06/2021 11.56, Andreas Beckmann wrote: > gdal can rename gdal-data to gdal3-data, build with > --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20. > Thus libgdal20 + gdal-data from buster should be co-installable with > libgdal28 + gdal3-data from bullseye and survive the upgrade if needed. > > A patch doing this is attached, I'm now testing the upgrade paths > (along the introduction of the libhdf5*-103 metapackages). > >>> > >>> If the gdal-data issue is solved, the next problem shows up: > >>> > >>> libgdal20 Depends: libogdi3.2 > >>> libgdal28 Depends: libogdi4.1 > >>> > >>> but the two ogdi library packages are not co-installable (both ship > >>> plugins in the same unversioned path). > >>> > >>> So even if we fix hdf5, libgdal20 is unlikely to be able to survive > >>> upgrades from buster. (Sime something that was built against libgdal20 > >>> in buster now likely depends on libgdal28 in bullseye) > >>> But I'd still like to add a Breaks: libgdal20 to libgdal28 to make this > >>> explicit, since transitive Breaks don't work well. > >> > >> I'm only willing to update gdal in unstable if the 3.2.2+dfsg-1 changes > >> don't need to be reverted. Since that goes against the freeze policy, > >> that's highly unlikely as the RMs seem unwilling to make exceptions. > > > > Is 3.2.2 a bugfix only release? > > It is. As mentioned in its NEWS: > > https://github.com/OSGeo/gdal/blob/v3.2.2/gdal/NEWS Thanks, that looks sane enough. I have unblocked gdal. Please go ahead with an upload adding a gdal3-data binary package. Cheers > > > Are there any changes in 3.2.2 that go > > beyond targetted fixes? > > I'd say no, see: > > https://github.com/OSGeo/gdal/compare/v3.2.1...v3.2.2 > > > Is there a policy that gdal upstream follows for > > picking patches for a bug fix release? > Its not codified, but upstream is sane with the commits to their > maintenance branches. > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/11/21 8:49 PM, Sebastian Ramacher wrote: > On 2021-06-09 12:41:29 +0200, Sebastiaan Couwenberg wrote: >> On 6/9/21 12:11 PM, Andreas Beckmann wrote: >>> On 08/06/2021 11.56, Andreas Beckmann wrote: gdal can rename gdal-data to gdal3-data, build with --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20. Thus libgdal20 + gdal-data from buster should be co-installable with libgdal28 + gdal3-data from bullseye and survive the upgrade if needed. A patch doing this is attached, I'm now testing the upgrade paths (along the introduction of the libhdf5*-103 metapackages). >>> >>> If the gdal-data issue is solved, the next problem shows up: >>> >>> libgdal20 Depends: libogdi3.2 >>> libgdal28 Depends: libogdi4.1 >>> >>> but the two ogdi library packages are not co-installable (both ship >>> plugins in the same unversioned path). >>> >>> So even if we fix hdf5, libgdal20 is unlikely to be able to survive >>> upgrades from buster. (Sime something that was built against libgdal20 >>> in buster now likely depends on libgdal28 in bullseye) >>> But I'd still like to add a Breaks: libgdal20 to libgdal28 to make this >>> explicit, since transitive Breaks don't work well. >> >> I'm only willing to update gdal in unstable if the 3.2.2+dfsg-1 changes >> don't need to be reverted. Since that goes against the freeze policy, >> that's highly unlikely as the RMs seem unwilling to make exceptions. > > Is 3.2.2 a bugfix only release? It is. As mentioned in its NEWS: https://github.com/OSGeo/gdal/blob/v3.2.2/gdal/NEWS > Are there any changes in 3.2.2 that go > beyond targetted fixes? I'd say no, see: https://github.com/OSGeo/gdal/compare/v3.2.1...v3.2.2 > Is there a policy that gdal upstream follows for > picking patches for a bug fix release? Its not codified, but upstream is sane with the commits to their maintenance branches. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 2021-06-09 12:41:29 +0200, Sebastiaan Couwenberg wrote: > On 6/9/21 12:11 PM, Andreas Beckmann wrote: > > On 08/06/2021 11.56, Andreas Beckmann wrote: > >> gdal can rename gdal-data to gdal3-data, build with > >> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20. > >> Thus libgdal20 + gdal-data from buster should be co-installable with > >> libgdal28 + gdal3-data from bullseye and survive the upgrade if needed. > >> > >> A patch doing this is attached, I'm now testing the upgrade paths > >> (along the introduction of the libhdf5*-103 metapackages). > > > > If the gdal-data issue is solved, the next problem shows up: > > > > libgdal20 Depends: libogdi3.2 > > libgdal28 Depends: libogdi4.1 > > > > but the two ogdi library packages are not co-installable (both ship > > plugins in the same unversioned path). > > > > So even if we fix hdf5, libgdal20 is unlikely to be able to survive > > upgrades from buster. (Sime something that was built against libgdal20 > > in buster now likely depends on libgdal28 in bullseye) > > But I'd still like to add a Breaks: libgdal20 to libgdal28 to make this > > explicit, since transitive Breaks don't work well. > > I'm only willing to update gdal in unstable if the 3.2.2+dfsg-1 changes > don't need to be reverted. Since that goes against the freeze policy, > that's highly unlikely as the RMs seem unwilling to make exceptions. Is 3.2.2 a bugfix only release? Are there any changes in 3.2.2 that go beyond targetted fixes? Is there a policy that gdal upstream follows for picking patches for a bug fix release? Cheers > > Kind Regards, > > Bas > > -- > GPG Key ID: 4096R/6750F10AE88D4AF1 > Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/9/21 12:11 PM, Andreas Beckmann wrote: > On 08/06/2021 11.56, Andreas Beckmann wrote: >> gdal can rename gdal-data to gdal3-data, build with >> --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20. >> Thus libgdal20 + gdal-data from buster should be co-installable with >> libgdal28 + gdal3-data from bullseye and survive the upgrade if needed. >> >> A patch doing this is attached, I'm now testing the upgrade paths >> (along the introduction of the libhdf5*-103 metapackages). > > If the gdal-data issue is solved, the next problem shows up: > > libgdal20 Depends: libogdi3.2 > libgdal28 Depends: libogdi4.1 > > but the two ogdi library packages are not co-installable (both ship > plugins in the same unversioned path). > > So even if we fix hdf5, libgdal20 is unlikely to be able to survive > upgrades from buster. (Sime something that was built against libgdal20 > in buster now likely depends on libgdal28 in bullseye) > But I'd still like to add a Breaks: libgdal20 to libgdal28 to make this > explicit, since transitive Breaks don't work well. I'm only willing to update gdal in unstable if the 3.2.2+dfsg-1 changes don't need to be reverted. Since that goes against the freeze policy, that's highly unlikely as the RMs seem unwilling to make exceptions. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 08/06/2021 11.56, Andreas Beckmann wrote: gdal can rename gdal-data to gdal3-data, build with --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20. Thus libgdal20 + gdal-data from buster should be co-installable with libgdal28 + gdal3-data from bullseye and survive the upgrade if needed. A patch doing this is attached, I'm now testing the upgrade paths (along the introduction of the libhdf5*-103 metapackages). If the gdal-data issue is solved, the next problem shows up: libgdal20 Depends: libogdi3.2 libgdal28 Depends: libogdi4.1 but the two ogdi library packages are not co-installable (both ship plugins in the same unversioned path). So even if we fix hdf5, libgdal20 is unlikely to be able to survive upgrades from buster. (Sime something that was built against libgdal20 in buster now likely depends on libgdal28 in bullseye) But I'd still like to add a Breaks: libgdal20 to libgdal28 to make this explicit, since transitive Breaks don't work well. Andreas
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 08/06/2021 12.22, Sebastiaan Couwenberg wrote: Please spend your time on other more deserving packages. I'm not caring that much about postgis but about getting clean upgrade paths if hdf5 and or gdal are involved because of the (transitive) non-co-installability of libhdf5*-103/libhdf5*-103-1 and libgdal20/libgdal28 which sometimes result in partial upgrades (keeping buster versions installed while packages could be upgraded to bullseye) or unwanted removals (removing the package rather than upgrading it to the bullseye version). Andreas
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
On 6/8/21 11:56 AM, Andreas Beckmann wrote: > Package: release.debian.org > Severity: normal > > Let's start with the debian-release@ discussion here, this may be turned > into an unblock request later. > > On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder wrote: >> One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a >> Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0, >> and postgresql-11-postgis-2.5 depends on that. libgdal28 depends on >> gdal-data (>=3.2.1+dfsg-1). To me it looks like there's no way to >> keep postgresql-11-postgis-2.5 around if anything that depends on >> libgdal28 (postgis, libopencv-imgcodecs4.5, ...) gets installed. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988722#31 > > gdal can rename gdal-data to gdal3-data, build with > --datadir=/sur/share/gdal3 and drop the Breaks on libgdal20. > Thus libgdal20 + gdal-data from buster should be co-installable with > libgdal28 + gdal3-data from bullseye and survive the upgrade if needed. > > A patch doing this is attached, I'm now testing the upgrade paths > (along the introduction of the libhdf5*-103 metapackages). > > A good gdal bug to reuse would be #986975 > > Updating gdal may be a bit more tricky, because testing has 3.2.1 while > sid has 3.2.2. gdal won't be updated in unstable before the bullseye release as mentioned in #986975. You don't need to worry about the old postgis, using pg_upgradecluster for postgis databases is not supported. PostGIS databases need to be recreated after the distribution upgrade or hacks need to be used, this is nothing new (but hopefully the bookworm distribution upgrade will be better if it also has postgis 3.x). Please spend your time on other more deserving packages. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28
Package: release.debian.org
Severity: normal
Let's start with the debian-release@ discussion here, this may be turned
into an unblock request later.
On Tue, 18 May 2021 20:36:23 +0200 Dennis Filder wrote:
> One more observation: Bullseye's gdal-data 3.2.1+dfsg-1 defines a
> Breaks: libgdal20 (< 2.5.0~), but the libgdal20 in Buster is 2.4.0,
> and postgresql-11-postgis-2.5 depends on that. libgdal28 depends on
> gdal-data (>=3.2.1+dfsg-1). To me it looks like there's no way to
> keep postgresql-11-postgis-2.5 around if anything that depends on
> libgdal28 (postgis, libopencv-imgcodecs4.5, ...) gets installed.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988722#31
gdal can rename gdal-data to gdal3-data, build with
--datadir=/sur/share/gdal3 and drop the Breaks on libgdal20.
Thus libgdal20 + gdal-data from buster should be co-installable with
libgdal28 + gdal3-data from bullseye and survive the upgrade if needed.
A patch doing this is attached, I'm now testing the upgrade paths
(along the introduction of the libhdf5*-103 metapackages).
A good gdal bug to reuse would be #986975
Updating gdal may be a bit more tricky, because testing has 3.2.1 while
sid has 3.2.2.
Andreas
diff -Nru gdal-3.2.1+dfsg/debian/changelog gdal-3.2.1+dfsg/debian/changelog
--- gdal-3.2.1+dfsg/debian/changelog2021-01-04 13:49:29.0 +0100
+++ gdal-3.2.1+dfsg/debian/changelog2021-06-07 09:02:51.0 +0200
@@ -1,3 +1,12 @@
+gdal (3.2.1+dfsg-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename gdal-data to gdal3-data and build with --datadir=/usr/share/gdal3.
+This is a workaround for upgrade issues caused by libgdal20 (in buster)
+and libgdal28 (in bullseye) not being co-installable. (Closes: #xx)
+
+ -- Andreas Beckmann Mon, 07 Jun 2021 09:02:51 +0200
+
gdal (3.2.1+dfsg-1) unstable; urgency=medium
* New upstream release.
diff -Nru gdal-3.2.1+dfsg/debian/control gdal-3.2.1+dfsg/debian/control
--- gdal-3.2.1+dfsg/debian/control 2021-01-04 13:44:44.0 +0100
+++ gdal-3.2.1+dfsg/debian/control 2021-06-07 09:02:51.0 +0200
@@ -68,7 +68,7 @@
Package: libgdal28
Architecture: any
Section: libs
-Depends: gdal-data (>= ${source:Version}),
+Depends: gdal3-data (>= ${source:Version}),
${shlibs:Depends},
${misc:Depends}
Recommends: proj-bin
@@ -189,11 +189,10 @@
namely gdal_translate, gdalinfo, gdaladdo, gdalwarp, ogr2ogr, ogrinfo,
ogrtindex.
-Package: gdal-data
+Package: gdal3-data
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}
-Breaks: libgdal20 (<< 2.5.0~)
Description: Geospatial Data Abstraction Library - Data files
GDAL is a translator library for raster geospatial data formats.
As a library, it presents a single abstract data model to the
diff -Nru gdal-3.2.1+dfsg/debian/gdal-data.install
gdal-3.2.1+dfsg/debian/gdal-data.install
--- gdal-3.2.1+dfsg/debian/gdal-data.install2020-10-20 05:44:12.0
+0200
+++ gdal-3.2.1+dfsg/debian/gdal-data.install1970-01-01 01:00:00.0
+0100
@@ -1 +0,0 @@
-usr/share/gdal
diff -Nru gdal-3.2.1+dfsg/debian/gdal-data.lintian-overrides
gdal-3.2.1+dfsg/debian/gdal-data.lintian-overrides
--- gdal-3.2.1+dfsg/debian/gdal-data.lintian-overrides 2020-10-24
06:58:20.0 +0200
+++ gdal-3.2.1+dfsg/debian/gdal-data.lintian-overrides 1970-01-01
01:00:00.0 +0100
@@ -1,6 +0,0 @@
-# Not a problem
-national-encoding usr/share/gdal/s57expectedinput.csv
-
-# Not documentation
-package-contains-documentation-outside-usr-share-doc usr/share/gdal/pci_*.txt
-
diff -Nru gdal-3.2.1+dfsg/debian/gdal3-data.install
gdal-3.2.1+dfsg/debian/gdal3-data.install
--- gdal-3.2.1+dfsg/debian/gdal3-data.install 1970-01-01 01:00:00.0
+0100
+++ gdal-3.2.1+dfsg/debian/gdal3-data.install 2021-06-07 09:02:01.0
+0200
@@ -0,0 +1 @@
+usr/share/gdal3
diff -Nru gdal-3.2.1+dfsg/debian/gdal3-data.lintian-overrides
gdal-3.2.1+dfsg/debian/gdal3-data.lintian-overrides
--- gdal-3.2.1+dfsg/debian/gdal3-data.lintian-overrides 1970-01-01
01:00:00.0 +0100
+++ gdal-3.2.1+dfsg/debian/gdal3-data.lintian-overrides 2021-06-07
09:01:48.0 +0200
@@ -0,0 +1,6 @@
+# Not a problem
+national-encoding usr/share/gdal3/s57expectedinput.csv
+
+# Not documentation
+package-contains-documentation-outside-usr-share-doc usr/share/gdal3/pci_*.txt
+
diff -Nru gdal-3.2.1+dfsg/debian/rules gdal-3.2.1+dfsg/debian/rules
--- gdal-3.2.1+dfsg/debian/rules2021-01-04 13:44:33.0 +0100
+++ gdal-3.2.1+dfsg/debian/rules2021-06-07 09:02:46.0 +0200
@@ -117,6 +117,7 @@
override_dh_auto_configure:
for V in $(PYVERS); do \
PYTHON=/usr/bin/python$$V ./configure --prefix=/usr \
+ --datadir=\$$\{prefix\}/share/gdal3 \
--mandir=\$$\{prefix\}/share/man \
--includedir=\$$\{prefix\}/include/gdal \
--with-hide-internal-symbols=yes \
