"Official" Debian package?

[LebedevRI]

Would there be any interest, in addition to providing the existing "linux binary archive", to also provide a debian package repository?

After running into inadequacies of the existing debian package, i've took a stab at creating a package for minizinc+gecode+chuffed from scratch, and honestly the results make me sad. On a simple-ish model, it's already 30-40% faster than debian package:

``` $ time minizinc --solver gecode unreachable.entry.json.mzn ---------- real 0m1.406s user 0m1.341s sys 0m0.056s $ time minizinc --solver gecode unreachable.entry.json.mzn ---------- real 0m1.434s user 0m1.351s sys 0m0.076s $ time minizinc --solver chuffed unreachable.entry.json.mzn ---------- real 0m0.726s user 0m0.686s sys 0m0.040s $ time minizinc --solver chuffed unreachable.entry.json.mzn ---------- real 0m0.725s user 0m0.676s sys 0m0.048s ``` ``` $ time minizinc --solver gecode unreachable.entry.json.mzn ---------- real 0m0.939s user 0m0.883s sys 0m0.056s $ time minizinc --solver gecode unreachable.entry.json.mzn ---------- real 0m0.941s user 0m0.886s sys 0m0.056s $ time minizinc --solver gecode_presolver unreachable.entry.json.mzn ---------- real 0m0.925s user 0m0.904s sys 0m0.020s $ time minizinc --solver gecode_presolver unreachable.entry.json.mzn ---------- real 0m0.911s user 0m0.887s sys 0m0.024s $ time minizinc --solver chuffed unreachable.entry.json.mzn ---------- real 0m0.410s user 0m0.382s sys 0m0.028s $ time minizinc --solver chuffed unreachable.entry.json.mzn ---------- real 0m0.405s user 0m0.381s sys 0m0.024s ```

[LebedevRI]

cc @kaol

[Dekker1]

We already provide a AppImage, Snap package, and a binary archive that is compatible with as many linux distributions as we can feasible make it. Each of these targets already works on the latest debian release to my knowledge. Just maintaining these targets has already proven a lot of work, so (speaking for myself) I would not like to add another linux target to that list.

The fix from the debian side also seems quite straightforward. From your previous issues it is clear that you are running a debug build of the MiniZinc compiler. If debian switches its build to a Release build, that would likely correspond to the ~40% slowdown.

[LebedevRI]

We already provide a AppImage, Snap package, and a binary archive that is compatible with as many linux distributions as we can feasible make it. Each of these targets already works on the latest debian release to my knowledge. Just maintaining these targets has already proven a lot of work, so (speaking for myself) I would not like to add another linux target to that list.

The fix from the debian side also seems quite straightforward. From your previous issues it is clear that you are running a debug build of the MiniZinc compiler. If debian switches its build to a Release build, that would likely correspond to the ~40% slowdown.

If only it were that simple :) Not exactly. That helps with only half of that slowdown, i get another -16..-20% improvement from LTO and 2-stage PGO, and i haven't finished dialing it to 11 yet :)

I would love debian to do the right thing, but that would require active help from the current maintainer with no disagreements on the road taken. I don't think that will happen. @kaol ?

[kaol]

If you have already sent a patch with the compile flags you'd like to see used I must have missed it and I'll have to ask you to send it again. If you haven't then I think it's unreasonable to begin with asking whether I'd do the "right thing".

If you're going to go for a binary outside of a distribution I don't see what benefit having a deb would give.

[LebedevRI]

Oh, hi! Thanks for updating gecode / minizinc packages.

If you have already sent a patch with the compile flags you'd like to see used I must have missed it and I'll have to ask you to send it again.

I have not sent anything yet.

If you haven't then I think it's unreasonable to begin with asking whether I'd do the "right thing".

Locally, i've ended up with this monstrosity: https://github.com/Lebedevri/minizinc-meta This is not how, i guess, it should be done in debian proper, but that was what worked for me locally, and could work for an "official" package.

Roughly, the "right thing", in an increasing order of unlikehood:

1. Build gecode/chuffed/minizinc/minizincide/etc with -DCMAKE_BUILD_TYPE=Release+CFLAGS=CXXFLAGS="-O3 -DNDEBUG". Now, nowadays i'm not actually sure this is a good idea. There is a number of faulty assertions and whatnot even in latest releases of forementioned packages.
2. Additionally add -DCMAKE_C_VISIBILITY_PRESET=hidden -DCMAKE_CXX_VISIBILITY_PRESET=hidden -DCMAKE_VISIBILITY_INLINES_HIDDEN=ON
3. Enable LTO for these packages
4. Ensure that hardening is disabled for these packages (contentious?)
5. Create <template>pkg-constraint-programming</template> debian salsa org (and perhaps a team), and move packaging repositories there (+ other solvers, plus likely z3)
6. Package minizinc-python
7. Run libminizinc tests using minizinc-python
8. This maybe also allows to enable tests for gecode/chuffed packages. Not sure.
9. Make gecode/chuffed/minizinc packaging more complicated by exploiting libminizinc "test coverage" to produce a PGO-enabled builds. Yes, this may require staggered package re-uploads with different build profiles.
10. Specifically use clang instead of gcc. (i'd put this much higher in the list, but it's not technically required earlier)
11. ... that enables us to do a second round of CS-PGO
12. Also add a third round of PGO via llvm bolt
13. Package HIGHS/SCIP (not unlikely)

None of this requires having a meta-build package, but it effectively results in me hijacking packaging maintainership for these packages, which is why i'm not sure if this can actually happen.

[kaol]

This really isn't the place to have this discussion, I invite you to take it to https://lists.debian.org/debian-science/

[LebedevRI]

Yeah that is beyond my current abilities.

[Dekker1]

It sounds to me like there is more than enough willingness to solve this issue on the Debian side. I’ll close this issue here.

[LebedevRI]

Hm, and current debian packages (minizinc+chuffed) is even 5 times slower, not 40%. That is kind-of funny.

[Dekker1]

I think you have found some good compilation improvements, and they are likely to be more impactful on longer runs of MiniZinc (and its solvers). It just seems all the more reason to me to get in contact with the Debian maintainers and help them understand what is currently going wrong.