Just some clarifications:
As Jochen said:
> Reason: The package in testing is RC buggy with #930507. Leo pushed a
> new -3 revision over a week ago to unstable but expressed in
> https://lists.debian.org/debian-release/2019/06/msg00526.html
>
> that he is not 'very happy with the patches'.
he missed the final sentence ... but "they are valid". When I was saying that I
was not happy I asked three possible options and I didn't receive any answer. I
just create another set of patch different from upstream to solve the same and I
don't think that it was a good idea (not follow Upstream solving the same). And
the most formal solution should be to use the Depends field of pkg-config.
The bug mentioned the dependencies of the pkgfile about the includes and that
was solved. The problem has been that I introduce a more strong dependency
(libode-dev)
After discussing the state
> in #debian-release today, I had a look at the -3 version and tested it
> using
>
> http://ompl.kavrakilab.org/RigidBodyPlanningWithIntegrationAndControls_8cpp_source.html
>
> and
>
> g++ $(pkg-config --cflags --libs ompl) -o
> RigidBodyPlanningWithIntegrationAndControls
> RigidBodyPlanningWithIntegrationAndControls.cpp
>
> I found that that libompl-dev was still missing dependencies, i.e.
> libode-dev and boost.
boost is added, Jochen do it. But libode no. I just solved the pkg issue but I
didn't pay attention that that changed brought the libode-dev. You only need
libode if you use one extension. For instance, the example that Jochen mentioned
generate:
g++ -I/usr/include/eigen3 -lompl /usr/lib/x86_64-linux-gnu/libode.so
/usr/lib/x86_64-linux-gnu/libboost_serialization.so
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so
/usr/lib/x86_64-linux-gnu/libboost_system.so -lpthread -o
RigidBodyPlanningWithIntegrationAndControls
RigidBodyPlanningWithIntegrationAndControls.cpp
if I drop the ode part (/usr/lib/x86_64-linux-gnu/libode.so) the program
compiles and links perfectly, and runs. If I uninstall libode-dev the program
works (and builds without the libode.so). Only needs libode-dev because
pkg-config add that flag. And it added because if you use the ode extension in
theory you need to link against it, but it's not clear to me. libompl is linked
against ode because that extension, but if you don't use any ode symbols I think
that you don't need to link against it.
> Given that the deadline for change in buster passed and the package would need
> more review to get fixed, I propose to drop it from the buster release.
It's a pity and a sad thing to me. I have been working with this package and
tried to keep it in a good shape and now because a last time bug, bad resolved
and with a simple solution (change Suggest to depends of libode-dev) it's out of
buster.
I have pushed a new version replacing my patches with an adaptation of upstream
patches to solve the problem from here:
https://bitbucket.org/ompl/ompl/commits/e3855102b037643a9625ff6694bb2f559eecb411
Here my patches:
https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0002-Patch-from-upstream-to-add-include-dirs.patch
https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0003-Patch-from-upstream-to-add-include-dirs-to-pkg-confi.patch
https://salsa.debian.org/science-team/ompl/blob/master/debian/patches/0004-Patch-from-upstream-to-add-include-dirs-to-pkg-confi.patch
Leopold
--
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
