Packaging Gecode twice to have newer snapshot for Minizinc
From
Kari Pahula@21:1/5 to
All on Fri Jun 28 20:10:01 2024
I have an unhappy situation with Gecode and Minizinc.
Gecode offers two things: A shared C++ library, and a flatzinc
programming language implementation.
Minizinc is a programming language as well, whose implementation works
by turning minizinc programs to flatzinc and uses an implementation to
execute it. Much like the numerous languages outputting C or JS.
Minizinc also requires Gecode library to compile itself, but that's an independent use from invoking a flatzinc executable.
Indeed, flatzinc has multiple implementations and minizinc has support
for picking one among them. Gecode's is just the default one and the
one minizinc is bundled with in their upstream binaries. Debian has
two others packaged, chuffed and ortools. Unfortunately chuffed is
only a partial implementation and ortools is currently uninstallable
and updating it is pending on absl library upgrade (which is no mean
feat).
Gecode has last had a release in 2019 and the flatzinc implementation
offered by it is not sufficient to run current minizinc programs. A
new Gecode release would be ideal but unfortunately prodding upstream
is unlikely to have any quick results as the person who used to do
them has passed away since. Minizinc is actively developed and has
frequent releases.
The current release of Gecode is still sufficient for Minizinc's use
of it as a library and I expect it's going to remain that way.
Just packaging a Gecode snapshot would solve the issues, but it would
imply taking over the SONAME and I'm not willing to do that. ABI
changes are upstream's call.
I'm considering packaging Gecode again as gecode-snapshot and also
keep the original gecode package. I'd remove the flatzinc executable
from the original and only offer flatzinc from gecode-snapshot.
Alternatively I could pick another flatzinc as a default. None of the currently packaged options are up to the task and I'd have to pick yet
another one to package. There are options, some of which are free
software.
Another option would be to update to the snapshot and still offer a
library but move it to some private directories and tell minizinc to
use it from there and users to not touch it. There are no current
rdepends on it other than minizinc. It wouldn't serve well any users
who would be using the library and it'd feel making an even more of a
special case of this compared to just going with gecode-snapshot.
If nobody objects I'll proceed with an ITP on gecode-snapshot. If and
when upstream makes a release I'll retire the package.
This all relates to #1073819. I looked at it but there's a limit to
what I can do to enable minizinc's features without touching the ABI.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)