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
Reply to: