On Sat, Jan 14, 2006 at 06:02:34PM +0100, Adeodato Simó wrote: > * Florian Ernst [Fri, 13 Jan 2006 21:52:26 +0100]: > > > I gave some pointers on relibtoolizing to my sponsees after vorlon > > called for improved library handling as mentioned in > > <http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html>. > > Especially KDE applications seem to be prone to depend on a plethora > > of packages they don't really need for functioning due to the admin/ > > subdir as shipped by kdevelop, so relibtoolizing can save a great deal > > here. > > Are these instructions in a form suitable to make them public? :) Uhh, I didn't see a need for making those short pointers public, as I thought Steve's mail[0] basically contained enough hints, examples and pointers to get everyone started on this issue; but I might have erred on this side, soooo... Somewhere else in this thread it was already mentioned that sometime stupidly written macros may cause problems when doing "normal" relibtoolization in order to use Debian's libtool, and indeed those various *-config scripts don't quite seem to fit Debian's purposes. But I digress... Now some summary of my pointers with some use cases added: Generally speaking, a package maintainer should have (or acquire) some knowledge what his package really needs for functioning, so inspecting the source and particularly paying attention to the various headers that are #include'd is in order. If the deb's Depends line differs considerably from what one would expect after previous inspection, some improvement could be achieved. If one of the *-config scripts is used during the build process it's quite likely to blame. Steve already presented two common ways to hardcode an override for the script's output. Additionally, as we have heard somewhere else in this thread, relibtoolizing is a good thing to do unless Debian's libtool was already used, see Scott 'keybuk' James Remnant's instructions. I'll present a use case below. For KDE packages, though, relibtoolizing requires some extra steps due to their build setup. I've experienced good results using the latest autoconf, automake1.9 and libtool packages and issuing $ libtoolize --copy --force $ cp -f /usr/share/aclocal/libtool.m4 admin/libtool.m4.in $ make -f admin/Makefile.common in your package source tree and rebuilding the package. YMMV. For some packages it might help to add some $(MAKE) flags like e.g. LIB_QT="" to further reduce the libraries your binary will be linked against. I'll present a use case below. When relibtoolizing you need to make up your mind whether you want to add the corresponding instructions to your debian/rules and thus do it during build time or whether you prefer to do it once when generating your packaging and ship the updated files in the diff.gz. This thread has already seen people claiming the one or the other ought to be done and why, so I won't add to this now, but please note that in the latter case you'll need to add AM_MAINTAINER_MODE at the appropriate place in order to avoid timestamp skews as explained in the autotools documentation. Now let's get our hands wet, shall we? Package gnubik: Uses guile-config and pkg-config during build. 2.2-3 Depends on | Depends: guile-1.6-libs, libatk1.0-0 (>= 1.9.0), libc6 (>= 2.3.5-1), | libglib2.0-0 (>= 2.8.0), libglu1-xorg | libglu1, libgtk2.0-0 (>= | 2.6.0), libgtkglext1, libguile-ltdl-1, libice6 | xlibs (>> 4.1.0), | libpango1.0-0 (>= 1.8.2), libqthreads-12, libsm6 | xlibs (>> 4.1.0), | libx11-6 | xlibs (>> 4.1.0), libxmu6 | xlibs (>> 4.1.0), libxt6 | | xlibs (>> 4.1.0), xlibmesa-gl | libgl1 Passing LDFLAGS, LIBS, GUILE_LDFLAGS and gnubik_LDADD to $(MAKE) was sufficient to reduce this to | Depends: guile-1.6-libs, libc6 (>= 2.3.5-1), libglib2.0-0 (>= | 2.8.0), libglu1-xorg | libglu1, libgtk2.0-0 (>= 2.6.0), libgtkglext1, | libx11-6 | xlibs (>> 4.1.0), xlibmesa-gl | libgl1 for 2.2-4. Not that impressive, since the dropped packages are closely related to those that remained, so even though it looks nicer, the net gain was rather small and arguably not worth the effort. Package xmms-crossfade: Uses pkg-config, xmms-config, glib-config, gtk-config. 0.3.8-1 Depends on | Depends: libc6 (>= 2.3.5-1), libglib1.2 (>= 1.2.0), libgtk1.2 (>= | 1.2.10-4), libsamplerate0, libx11-6 | xlibs (>> 4.1.0), libxext6 | | xlibs (>> 4.1.0), libxi6 | xlibs (>> 4.1.0), xmms (>= | 1.2.10+cvs20050809) Passing XF_LIBS and libcrossfade_la_LIBADD to $(MAKE) was sufficient to reduce this to | Depends: libc6 (>= 2.3.5-1), libsamplerate0, xmms (>= | 1.2.10+cvs20050809) for 0.3.8-2. GLIB, GTK and X dependency gone, but the package actually working just as before, oh well. :) Package keurocalc (not one of my "own", merely sponsoring): Uses KDE's build setup. 0.9.4-4 Depends on | Depends: kdelibs4c2 (>= 4:3.4.2-1), libart-2.0-2 (>= 2.3.16), | libaudio2, libc6 (>= 2.3.5-1), libfam0, libfontconfig1 (>= 2.3.0), | libfreetype6 (>= 2.1.5-1), libgcc1 (>= 1:4.0.1), libice6 | xlibs (>> | 4.1.0), libidn11 (>= 0.5.18), libjpeg62, libpng12-0 (>= 1.2.8rel), | libqt3-mt (>= 3:3.3.5), libsm6 | xlibs (>> 4.1.0), libstdc++6 (>= | 4.0.2), libx11-6 | xlibs (>> 4.1.0), libxcursor1 (>> 1.1.2), libxext6 | | xlibs (>> 4.1.0), libxft2 (>> 2.1.1), libxi6 | xlibs (>> 4.1.0), | libxinerama1, libxrandr2 | xlibs (>> 4.3.0), libxrender1 (>> | 1:0.9.0-1), libxt6 | xlibs (>> 4.1.0), zlib1g (>= 1:1.2.1) Relibtoolizing as mentioned above boiled this down to | Depends: kdelibs4c2a (>= 4:3.4.3-1), libc6 (>= 2.3.5-1), libgcc1 (>= | 1:4.0.2), libqt3-mt (>= 3:3.3.5), libstdc++6 (>= 4.0.2-4) for 0.9.4-5. Touchdown (at the prize of a 825kb dpatch, in this case)! Among other things this package has now become unbundled from the pending and painful freetype transition. So, when delving (more or less) deep into your packages' internals not only you can learn quite a lot about the inner workings, but you could also just apply some tweaking to the build process and thus make your and the Release Managers' life easier in the future. :) Of course, when applying those changes, make sure to check and double-check using the usual suspects^Wtools like lintian, linda, debdiff, pbuilder, piuparts, ... Happy hacking, Flo [0] http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html
Attachment:
signature.asc
Description: Digital signature