Bug#610653: ITP: dmtcp -- Checkpoint/Restart functionality for Linux processes
On Mon, 31 Jan 2011, Kapil Arya wrote:
> PS: Please also have a look at libdmtcpaware1.postinst file. I have
> used the template and inserted the "ldconfig"; it suppressed lintian
> error/warning, but I am not sure if this is the correct way.
yeap -- should not have been necessary...
if you add a call to dh_makeshlibs in rules it should do that iirc
NB using debhelper 7 format of debian/rules I already started forgetting
about all those manual things ;-)
> > | dmtcp_1.2.0+svn864-1~nd09.04+1_i386.build FAILED
> > | dmtcp_1.2.0+svn864-1~nd09.04+1_amd64.build FAILED
> > `---
> This is where I have some problem reproducing the failure. I tried
> building it on Ubuntu9.10 and 10.10, both 32-bit, but it built just
> fine. I didn't see any issues. I tried by downloading the files from
> mentors.debian.net and then doing a dpkg-source followed by
> dpkg-buildpackage. Can you tell me how to reproduce these failures?
> Should I run a different set of commands?
the only obvious difference was that in my case it was '-B' build, i.e.
" binary-only build, limited to architecture dependent packages"; but I
do not see how it should have impacted the build... I will check
tomorrow in greater detail
> > * dynamic library
> > - -dev package should carry symlink for .so file, not the lib package
> > (carrying versioned one)
> Not sure if I understood it correctly. I have some doubts about the
> .so files and various versions of them which are often symlinks in
> either direction. So here are a few questions:
;-) should be quite uniform actually...
the ultimate source is the Debian bible :
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime
but at times it becomes too evolved, and many details are usually not
directly relevant since taken care of by dh_* helpers:
The run-time library package should include the symbolic link for the
SONAME that ldconfig would create for the shared libraries. For example, the
libgdbm3 package should include a symbolic link from /usr/lib/libgdbm.so.3 to
libgdbm.so.3.0.0. This is needed so that the dynamic linker (for example ld.so
or ld-linux.so.*) can find the library between the time that dpkg installs it
and the time that ldconfig is run in the postinst script.[50]
and then check section "8.4 Development files" for -dev package
The development package should contain a symlink for the associated
shared library without a version number. For example, the libgdbm-dev
package should include a symlink from /usr/lib/libgdbm.so to
libgdbm.so.3.0.0. This symlink is needed by the linker (ld) when
compiling packages, as it will only look for libgdbm.so when compiling
dynamically.
a bit more detailed reference would be
Debian Library Packaging guide
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
which is a bit aged as well but still has nice description on versions
> 1b. Currently, the toplevel Makefile is renaming the library from
> libdmtcpaware.so to libdmtcpaware.so.1. Is this the correct approach?
I bet there is a more 'standard' way... just would need to dig into
autotools manual... do not recall top of the head
> 2. Should libdmtcpaware1-dev package install a symlink
> /usr/lib/libdmtcpaware.so --> libdmtcpaware.so.1?
yes, but most probably unversioned -dev would be enough (i.e.
libdmtcpaware-dev)
> 3. I am really confused about the library versioning and symlinking.
> Can you provide me some pointers on this?
;-) above. The global reasoning : you might have multiple (so)versions
of libraries installed (i.e. libdmtcpaware1, libdmtcpaware2, ...), but
-dev will install a single symlink for the .so to point to the
corresponding (most uptodate) library
> I have made some changes, please have a look and tell me what to do. Thanks.
will have better look (and reproducing that error) tomorrow/day after
... meanwhile sortout symlinks/ldconfig issues
> I was not sure whether to put 1 of 1.0 or 1.0.0, so I chose the middle
> one :-). Changed to plain 1 now :-).
to say the truth... I do not recall if .so.major.minor.rev needs to be
enforced if soversion is just 'major' - shame on me... may be there is
no reason for full version, can't come up with 'why not' (time to go to
sleep I guess) -- I see few packages installing directly just
so.major... , so may be it would be ok as well.
may be I will figure it out tomorrow and will come back to scream here
;-)
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
Reply to: