Fwd: Re: .deb package from compiled libraries
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Oops, forgot to send this to the list as well.
- -------- Original Message --------
Subject: Re: .deb package from compiled libraries
Date: Wed, 11 Aug 2010 20:45:13 +0200
From: Niels Thykier <niels@thykier.net>
To: Zvi Dubitzky <DUBI@il.ibm.com>
On 2010-08-11 19:46, Zvi Dubitzky wrote:
> Hi
>
> I was able to build a good .deb package of a library . thanks
>
> I am not suer if you would like my following questions but there is a
> reason for them:
>
> 1. Is it possible to run pbuilder not in a chroot environment without
> using base.tgz , But from a local file tree ?
> I tried : pbuilder --debuid or pbuilder --use-pdebuild-internal but
> both use the base.tgz file.
>
Depending on exactly what you need, cowbuilder may or may not be what
you want.
If you want to modify this chroot, then you probably want to read man
cowbuilder/pbuilder about --login and --save-after-login
> 2) I was watching the output of the dh_command s that come out as the
> rules/ binary-arch: target run (pbuilder).
> It seems it is possible to build a .deb package from an existing tree
> of binaries/libraries that were pre compiled.
> What is the naming convention of such a tree path ? is it defined in
> the debian-policy ?
>
I believe the policy for this is "don't"; Debian works around the idea
of compiling everything from source.
Nevertheless, it is possible and you can see such a tree in
debian/$package/ after the build is done and before you clean (though
not trivial to do with pbuilder/cowbuilder)
I /think/ you can also regenerate that try by using something like:
dpkg -x $debfile .
dpkg --control $debfile
But I have not actually tested this.
> - Can dpkg-shlibdeps accept several libraries in one call ( not clean
> from the man pages) ?
Yes, When building the eclipse source package (eclipse, -rcp, -platform,
plugin-cvs, -jdt and -pde) we use the following to make it calculate the
dependencies for the eclipse-rcp package.
dh_shlibdeps -peclipse-rcp
- -l$(JAVA_HOME)/jre/lib/$(DEB_HOST_ARCH_CPU) \
-- -dDepends \
$(JNI_SO_PATH)/libswt-gtk-*.so \
$(JNI_SO_PATH)/libswt-atk-gtk-*.so \
$(JNI_SO_PATH)/libswt-awt-gtk-*.so \
$(JNI_SO_PATH)/libswt-cairo-gtk-*.so \
$(JNI_SO_PATH)/libswt-pi-gtk-*.so \
$(JNI_SO_PATH)/libswt-xpcominit-gtk-*.so \
$(JNI_SO_PATH)/libswt-xulrunner-gtk-*.so \
$(shell find $(JNI_SO_PATH) -name '*.so' | grep
- -v libswt-) \
$(LAUNCHER_LIB) \
-dRecommends \
$(JNI_SO_PATH)/libswt-gnome-gtk-*.so \
$(JNI_SO_PATH)/libswt-glx-gtk-*.so
NB: dh_shlibdeps is a debhelper wrapper for dpkg-shlibdeps, everything
after the "--" is passed directly to dpkg-shlibdeps.
For public shared libraries you may also want to maintain a symbols
file. Assuming you haven't heard about it - it tracks which symbols are
available in a library and helps you to make sure no symbols "disappear"
without you noticing it (e.g. ABI backwards compatibility broken). It is
also possible to use this to warn you when the public API/ABI is
expanded (see man dpkg-gensymbols for more).
It also helps the dpkg-shlibdeps to emit more precise versions for
reverse dependencies of your library - e.g. it may allow users to use an
older version of the library than reverse dependency was built against
(based on the symbols that the reverse dependency needs).
symbols files are superior to "shlibs" files, but shlibs appears to be
needed for the udeb files (see #571776)[1].
> - is the generation of the postinst and postrm scripts mandatory ?
>
Maintainer scripts are not mandatory in general as far as I know[2] -
they are used for library packages (to call ldconfig), though it may be
migrated to be using "file triggers" (see man deb-trigger and
dpkg-trigger) in the near future[3].
Note that debhelper (dh and all the dh_* commands run) may generate a
script for you/your package, since it is designed to handle common
cases. Particularly dh_makeshlibs auto generates postinst and postrm
snippets for library packages to call ldconfig for you (if you use
debhelper).
> - The pbuilder run output shows dpkg-deb is generating the final .deb
> file .
> What is the role of dpkg-buildpackage command (if any) that I do not
> see called explicitly ?
>
dpkg-buildpackage handles calling the commands to build the source
package as well as invoking the correct targets of debian/rules in your
build to build the package. By default it will also try to sign the
resulting changes and dsc files (if it knows your GPG key).
Other than that it calls dpkg-buildflags to set default variables (see
man dpkg-buildflags for more info) and checks that the build-depends are
installed (etc). Most/all of this is listed in the manpage of
dpkg-buildpackage.
> thanks
>
> Zvi Dubitzky
> Email:dubi@il.ibm.com
> IBM Haifa Research Laboratory Phone: +972-4-8296182
> Haifa, 31905, ISRAEL
>
>
>
~Niels
[1] Disclaimer - I do not maintain any packages producing udebs, so I
have no first hand knowledge of this. I just remembered seeing this bug.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571776
[2] Though the policy may mandate something that effectively requires
you to have a postinst or/and postrm script for certain packages (e.g.
See [8.1.1])
[3] Debian Policy [8.1.1] still mandates the use of ldconfig in the
scripts and I could not see any (obvious) bug against the policy
requesting this to be changed so I assume we are still doing this via
scripts.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEAREIAAYFAkxi9hsACgkQVCqoiq1YlqwvWwCfWpq/K89g6d2yVTko7Duv4Cak
E+MAoM8Vjvq2akmCOgwJ5lGFEwGT0nly
=cG8v
-----END PGP SIGNATURE-----
Reply to: