Re: dh_makeshlibs does not generate version info for some packages
On Wed, Feb 19, 2020 at 1:15 PM Andrey Rahmatullin <wrar@debian.org> wrote:
> On Wed, Feb 19, 2020 at 12:43:33PM +0100, Jędrzej Dudkiewicz wrote:
> > I have custom package (zs-boost_1.71.0_armhf.deb) that install libraries
> > to /opt/deps (which is not a big problem since we install on BeagleBone
> > with custom image on SD-card, also because of few exotic requirements it
> > is a necessity). I'm trying to build yet another package using libraries
> > from aforementioned package.
> I don't think you described whether the zs-boost package provides enough
> info about the libs it contains (so DEBIAN/shlibs and/or DEBIAN/symbols).
Thanks for an answer.
After:
ar xf zs-boost_1.71.0_armhf.deb
tar xf control.tar.gz
I have "shlibs" file with (partial output):
libboost_atomic 1.71.0 zs-boost
libboost_chrono 1.71.0 zs-boost
libboost_date_time 1.71.0 zs-boost
libboost_filesystem 1.71.0 zs-boost
libboost_iostreams 1.71.0 zs-boost
libboost_prg_exec_monitor 1.71.0 zs-boost
libboost_regex 1.71.0 zs-boost
So I'd say yes, yes it is.
> After all, that info is what is used to produce ${shlibs:Depends} in the
> depending packages.
Ok, after reading more perl scripts (so a language that I barely know
but dh_* scripts are rather nicely written) it seems that
dh_makeshlibs creates shlibs file which includes shared libraries
/provided/ by the package and dh_shlibdeps creates dependencies for
/libraries and program/. Also it seems that sh_shlibdeps calls
dpkg-shlibdeps and dpkg-shlibdeps /seems/ to use rpath from
executables and libraries, so I should be safe. But I'm not :)
> I also won't be surprised if our tools don't adequately support putting
> public shared libs into /opt instead of the usual paths.
I'd assume that chance that this is due cross-compilation are slim or
rather +/- none?
--
Jędrzej Dudkiewicz
I really hate this damn machine, I wish that they would sell it.
It never does just what I want, but only what I tell it.
Reply to: