Re: Forge packages recompiled against Octave 5 no longer depend on liboctave7
Now that the liboctave7 transition is over, let me revisit the issue:
* Rafael Laboissière <rafael@debian.org> [2019-10-05 00:39]:
* Sébastien Villemot <sebastien@debian.org> [2019-10-04 10:12]:
I don’t think injecting an artificial liboctaveN dependency is a
very good solution, because it violates the usual assumptions about
dependencies on shared libraries, and it goes against upstream’s
will to eliminate this dependency.
Nevertheless, I think we’ll have to design something along similar
lines. Either adding versioned dependencies against Octave as Mike
suggested, or introducing a virtual ABI package as is for example
done for R.
Yes, injecting an artificial liboctaveN dependency is not a perfect
solution. However, my code can be easily modified to inject the
virtual package octave-abi-N instead of liboctaveN. The octave
package must be changed such that the liboctaveN package provides
octave-abi-N. What do you think?
I already posted the instructions here, but let me give them again:
git clone git@salsa.debian.org:pkg-octave-team/dh-octave.git dh-octave
cd dh-octave
git checkout inject-liboctaveN
debuild -us -uc
sudo debi
This will install version 0.6.2.0~ in your system. This version contains
changes in dh_octave_substvar for injecting the appropriate dependency on
the virtual package octave-abi-N, according to the version of the octave
package used in the build. This is done only for add-on packages that
provide .oct and .mex files.
In order to make this work, we must also change the octave package to
make liboctaveN provide octave-abi-N.
Let me know what you think about this.
Rafael
Reply to: