Bug#998411: Bug#996204: Bug#998411: Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
On 2021-11-04 23:29:06 +0100, Anton Gladky wrote: > I have fixed gmsh. It will appear in NEW soon. Thanks, but unfortunately it was rejected. Cheers > > Regards > > Anton > -- Sebastian Ramacher signature.asc Description: PGP signature
Bug#998411: Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
On 2021-11-04 22:35, Drew Parsons wrote: On 2021-11-04 21:41, Sebastian Ramacher wrote: On 2021-11-03 22:33:01 +0100, Drew Parsons wrote: ... Is it best to revert back to strict Policy 8.1 compliance, which will slow down hypre patch release updates? Yes. Having to wait for binNEW to being processed is not an excuse to violate a must section of the policy. Fair enough. I'll make the change, either to libhypre2.22.2 or to libhypre-static. I've uploaded hypre 2.22.1-4 providing the shared libraries in libhypre-2.22.1 (and libhypre64 counterparts). I set libhypre-2.22.1 with Provides: libhypre (= 2.22.1), so petsc and sundials don't necessarily need to be recompiled. I also configured hypre to provide the static libraries, so we can consider whether to switch petsc and sundials to static hypre in the future (we might not want to. Shared libraries have other advantages apart from ABI management). Drew
Bug#998411: Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
I have fixed gmsh. It will appear in NEW soon. Regards Anton
Bug#998411: Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
On 2021-11-04 21:41, Sebastian Ramacher wrote: On 2021-11-03 22:33:01 +0100, Drew Parsons wrote: ... The problem that hypre 2.18.1-1 (un-versioned libhypre) intended to solve is that hypre is ABI-ignorant (https://github.com/hypre-space/hypre/issues/56), so each point patch release would have to be a new binary package, and the upstream release rate is faster than the average NEW queue processing rate (the new package for the current transition would be libhypre2.22.1, and already libhypre2.23.0 is released upstream). (So why is this packaged as shared library?) A reasonable question to ask. For my part, it was already being packaged as a shared library when I started working on it, so I just continued it so. I could imagine a clash of hypre symbols if a client programs links against both petsc and sundials (which both use hypre), and uses hypre directly. I guess the symbol table must guard against clashes like that. ... Is it best to revert back to strict Policy 8.1 compliance, which will slow down hypre patch release updates? Yes. Having to wait for binNEW to being processed is not an excuse to violate a must section of the policy. Processing of packages in NEW can take some time. I'm also waiting on some of them for months. The solution to that is however not to abondon well established practices for shared libraries. The problems that are caused by that can be seen with libhypre and its reverse dependencies. Fair enough. I'll make the change, either to libhypre2.22.2 or to libhypre-static. Drew
Bug#998411: Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
On 2021-11-03 22:33:01 +0100, Drew Parsons wrote: > On 2021-11-03 20:57, Sebastian Ramacher wrote: > > Source: hypre > > Severity: serious > ... > > The real blocker is hypre, specifically: > > > > hypre (2.18.1-1) experimental; urgency=medium > > . > >* Team upload. > >* New upstream release. > >* Standards-Version: 4.4.1 > >* Provide library binary package as libhypre without the soname > > version embedded in the package name. Enforce version dependency > > through strict shlibs dependency. This is to workaround lack of > > ABI backwards compatibility and keep minor version updates being > > delayed in the NEW queue. See README.Debian. > > > > > > As a consequence, hypre breaks co-installability of all its reverse > > dependencies, therefore breaking smooth updates of the packages involved > > in the transition. And yes, in the end, deal.ii currently keeps the > > whole stack from migrating as it renders deal.ii's binaries > > uninstallable in testing. > > > The problem that hypre 2.18.1-1 (un-versioned libhypre) intended to solve is > that hypre is ABI-ignorant (https://github.com/hypre-space/hypre/issues/56), > so each point patch release would have to be a new binary package, and the > upstream release rate is faster than the average NEW queue processing rate > (the new package for the current transition would be libhypre2.22.1, and > already libhypre2.23.0 is released upstream). (So why is this packaged as shared library?) > hypre has only 2 direct reverse dependencies, petsc and sundials, which we > can keep up-to-date easily. The current problem is that deal.ii depends on > the old petsc3.14, so it can't be installed with the new petsc3.15. That's why the second sentence of 8.1 reads: "This allows several versions of the shared library to be installed at the same time, allowing installation of the new version of the shared library without immediately breaking binaries that depend on the old version." The problem is not deal.ii. > It > wouldn't be a problem in practice, if deal.ii hadn't started FTBFS > (Bug#996277) preventing it rebuilding against petsc 3.15. We could say it > was tactical error running the hypre and petsc ABI updates at the same time > (I wasn't anticipating deal.ii Bug#996277) deal.ii doesn't FTBFS. deal.ii cannot currently be rebuilt in unsable because of another broken shared library (#995424 in gmsh). Once deal.ii is rebuilt (in testing), #996277 will disappear. > If we revert back to version-named hypre library packages then the cost is > that we won't be able to provide timely patch updates for hypre (each one > will be a new library package needing to pass NEW, since hypre does not > provide ABI compatibility). > > The alternative for this transition is to remove deal.ii from testing, which > is happening anyway due to Bug#996277 It won't be removed. > So the use of un-versioned libhypre was intended as a specific exception to > Policy 8.1, for the purpose of facilitating faster hypre patch updates. The > irregularity is due to a lack of ABI-awareness in hypre itself. > > Is it best to revert back to strict Policy 8.1 compliance, which will slow > down hypre patch release updates? Yes. Having to wait for binNEW to being processed is not an excuse to violate a must section of the policy. Processing of packages in NEW can take some time. I'm also waiting on some of them for months. The solution to that is however not to abondon well established practices for shared libraries. The problems that are caused by that can be seen with libhypre and its reverse dependencies. Cheers -- Sebastian Ramacher
Bug#998411: Bug#996204: transition: numerical library stack: hypre SONAME (Policy 8.1)
On 2021-11-03 20:57, Sebastian Ramacher wrote: Source: hypre Severity: serious ... The real blocker is hypre, specifically: hypre (2.18.1-1) experimental; urgency=medium . * Team upload. * New upstream release. * Standards-Version: 4.4.1 * Provide library binary package as libhypre without the soname version embedded in the package name. Enforce version dependency through strict shlibs dependency. This is to workaround lack of ABI backwards compatibility and keep minor version updates being delayed in the NEW queue. See README.Debian. As a consequence, hypre breaks co-installability of all its reverse dependencies, therefore breaking smooth updates of the packages involved in the transition. And yes, in the end, deal.ii currently keeps the whole stack from migrating as it renders deal.ii's binaries uninstallable in testing. The problem that hypre 2.18.1-1 (un-versioned libhypre) intended to solve is that hypre is ABI-ignorant (https://github.com/hypre-space/hypre/issues/56), so each point patch release would have to be a new binary package, and the upstream release rate is faster than the average NEW queue processing rate (the new package for the current transition would be libhypre2.22.1, and already libhypre2.23.0 is released upstream). hypre has only 2 direct reverse dependencies, petsc and sundials, which we can keep up-to-date easily. The current problem is that deal.ii depends on the old petsc3.14, so it can't be installed with the new petsc3.15. It wouldn't be a problem in practice, if deal.ii hadn't started FTBFS (Bug#996277) preventing it rebuilding against petsc 3.15. We could say it was tactical error running the hypre and petsc ABI updates at the same time (I wasn't anticipating deal.ii Bug#996277) If we revert back to version-named hypre library packages then the cost is that we won't be able to provide timely patch updates for hypre (each one will be a new library package needing to pass NEW, since hypre does not provide ABI compatibility). The alternative for this transition is to remove deal.ii from testing, which is happening anyway due to Bug#996277 So the use of un-versioned libhypre was intended as a specific exception to Policy 8.1, for the purpose of facilitating faster hypre patch updates. The irregularity is due to a lack of ABI-awareness in hypre itself. Is it best to revert back to strict Policy 8.1 compliance, which will slow down hypre patch release updates? Drew
