Am Samstag, dem 19.02.2022 um 23:13 +0100 schrieb Jochen Sprickerhof: > * Markus Koschany <a...@debian.org> [2022-02-19 22:38]: > > Ok. Did you file an upstream bug report already? > > I did not yet. Upstream bundles the old binary version so I don't think > I can convince them to do a quick migration. > But I will open a bug to get it fixed there. > > > The old version of H2 is already present in Ubuntu or Debian stable. You > > could > > either ask users to execute all those commands manually (README.Debian, > > Debian.NEWS) or there could be some kind of pre/post hook script that does > > all > > that automatically. > > Asking users to install packages from other releases does not sound > convincing. We can't use the pre/post maintainer scripts as the database > files could be stored anywhere on disk (default is in $HOME but could > even be on a thumb drive). So we can only hook into the jameica > executable. I don't think doing this before the Ubuntu jammy freeze is > feasible.
I believe there is a misunderstanding somewhere. We don't need to ask users to install anything. They simply upgrade from an older version to a newer one. There must be some sort of logic for the database storage. It is possible to move a file to a different location but your program will always look in the same place. If your database isn't there, then a good script would ask where it is, you enter the new location and the program proceeds. > > For a quick solution you could upload 1.4.197 again based on the version in > > Bullseye > > Thanks, I will do that, i.e. I will upload 2.1.210+really1.4.197-1 = > 1.4.197-4+deb11u1 as proposed in my initial bug report. > > > but this doesn't really solve the problem. > > Can you explain what you mean here? You only fix your single use case. You keep an unsupported and buggy version of the H2 database in Debian and this is not how we usually solve problems in Debian. > > As I said we don't need multiple H2 versions in Debian. > > Can you give reasons why you think so? As I stated multiple times I > don't see a way not to have multiple versions available in one release > to support the migration. You don't need multiple version of H2 in Bookworm. We ship 1.4.197 in Bullseye and 2.x in Bookworm, that's it. When users upgrade from Bullseye to Bookworm, they either have to perform some manual migration steps, or the package takes care of them automatically. That's how it works for every package in Debian. We also don't ship multiple Tomcat or Jetty, MariaDB or PostgreSQL versions in stable releases because we support only one of them for their life cycle. This is because of security and maintenance reasons, otherwise we would have multiple versions of every piece of Java software in Debian and we could stop using system libraries and instead bundle everything together in fat jars. At one point you have to upgrade to a newer H2 database, that's a fact and it should happen before we freeze for Bookworm. > > You should only do that if you are willing to > > support an officially unsupported piece of software for the next Debian 12 > > LTS > > cycle until the year 2028. And that means taking care of all other libh2- > > java > > dependencies too, dealing with people who request an upgrade to 2.x because > > their use case depends on it, etc. And you and the rest of the users should > > be > > fine with the disabled H2 console and all the other bugs in that version. > > That would be fine with me. Ok, that's your choice but please add yourself to the list of Uploaders and keep an eye on all H2 bug reports from now on because I won't. ;>
signature.asc
Description: This is a digitally signed message part
