OR-Tools as a Debian/Ubuntu package?

[Thiago Martins]

Hello,

 Is there interest, or anyone working on build OR-Tools on Debian as an official package?

 Or, to start, maybe an Ubuntu PPA, and then work to polish the Debian packaging to make it available from Debian later on?

Best,

Thiago

[Laurent Perron]

it is on our todo list, but there are much higher priority things to do.

Any help, initiative is always welcome.

Laurent Perron | Operations Research | lpe...@google.com | (33) 1 42 68 53 00

--
You received this message because you are subscribed to the Google Groups "or-tools-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to or-tools-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/or-tools-discuss/808bdb1a-4827-4c3e-a4f1-a7b56c76a3a1n%40googlegroups.com.

[Mizux Seiha]

You may be interested in our docker Debian stack: https://github.com/google/or-tools/tree/stable/cmake/docker/debian

From top of my head, my may concern would be (here, number are just for better communication):

1. We should generate it using the CMake based build

2. Need to add rpm/deb stuff using CMake package module or doing it externally ?

3. Update CMake to prefix option with `ORTOOLS_` (breaking CMake change so I want to push it asap)

4. Verify our CMake install rules are clean (docker C++ should already test it but need to double check)
5. Need a recent CMake >= 3.14 (mainly for using the new built-in swig module)

6. We should only provide a package with the C++ libraries (i.e. disable Python, Java, .Net wrappers)

7. Need to disable SCIP to follow the "Debian Free Software Guidelines" (currently no CI to check it works)
(note: gurobi is a runtime optional deps so no problem here)

8. Have a working Cbc/Clp libraries stack available on Debian (last stable release has broken our use case see https://github.com/coin-or/Clp/issues/130 ).

9. Have an abseil-cpp C++17 package available since OR-Tools target C++17 (note we are using few structured binding).

10. Check OR-Tools build against Debian system wide dependencies package (gcc?, zlib, protobuf, coin-or, abseil-cpp)

 Point 9 is a big challenge, I never see any distro package manager having some packages whose library consumption break if you don't use the same C++ language dialect in your dependent project.

see: https://github.com/abseil/abseil-cpp/blob/master/FAQ.md#what-is-abi-and-why-dont-you-recommend-using-a-pre-compiled-version-of-abseil
related issue: https://discourse.brew.sh/t/abseil-and-c-revision/8641

In homebrew-core (OSS package manager for Apple) since there were only 3 projects depending on abseil-cpp, I manage to push everyone to use C++17 thus I was able to submit/integrate or-tools to this ecosystem...

[Thiago Martins]

That's great! I'll make another thread then, so we can start talking about the details of this task.

[Calvin Kroese]

Has there been any progress on this?

On Thursday, February 4, 2021 at 5:06:45 PM UTC-5 Laurent Perron wrote: