Re: dpkg and debhelper patches for lib64 support
On Wednesday 18 June 2003 00:32, Joey Hess wrote:
> >
> > Note that an increasing number of packages already installs to
> > debian/tmp/usr/lib64 or need to be configured for
> > - --libdir="\${prefix}/${libname}", so doing it at install time only is
> > no real option unless you want to move debian/tmp/usr/lib64 (and
> > others) to debian/tmp/usr/lib at build time and back at install time...
>
> Seems to me we would want dpkg to deal with this, it would just leave
> files already in /usr/lib64 alone. It would need to check for file
> conflicts introduced by the remapping, but then you'd want to check for
> those anyway, in case someone set up this mapping:
>
> any /usr/doc/ /usr/share/doc/
> any /usr/man/ /usr/share/man/
>
> It's my understanding that directory remapping (and discarding) is
> already slated for dpkg 2.0. I don't know at what stage its design is,
> but all that's needed I think is to add an architecture field to that
> design, to make a given remapping only apply to packages from a given
> architecture.
>
> Doesn't this avoid the entire need for complicated substitutions in
> debian/rules and debhelper files?
>
This doesn't seem to work. Let's take aalib again as example
> diff -urN aalib-1.4p5/debian/rules aalib-1.4p5.new/debian/rules
> --- aalib-1.4p5/debian/rules 2003-06-08 15:11:51.000000000 +0000
> +++ aalib-1.4p5.new/debian/rules 2003-06-08 15:10:11.000000000 +0000
> @@ -3,12 +3,16 @@
> # This has to be exported for some stuff below to work.
> export DH_OPTIONS
>
> +libname=$(shell /usr/bin/dpkg-libinfo -qDEB_LIBNAME)
> +libdir=$(shell /usr/bin/dpkg-libinfo -qDEB_LIBDIR)
> +
> build: build-stamp
> build-stamp:
> dh_testdir
> ln -sf /usr/share/automake/depcomp # currently needed by automake
> ./configure --prefix=/usr --infodir=/usr/share/info \
> - --mandir=/usr/share/man
> + --mandir=/usr/share/man \
> + --libdir=\$${exec_prefix}/$(libname)
We need to add the libdir option to configure so that we don't break any
upstream dependency on libdir, e.g. dynamically loading libraries from the
libdir location or using rpath. This means that install already installs to
/usr/lib64 on lib64 platforms.
> $(MAKE)
> $(MAKE) -C doc
> touch build-stamp
> @@ -25,17 +29,17 @@
> dh_testdir
> dh_testroot
> dh_clean -k
> - dh_installdirs usr/lib usr/include
> + dh_installdirs ./$(libdir) usr/include
Since make install installs to libdir we have also to adapt the creation of
directories.
> $(MAKE) install prefix=`pwd`/debian/tmp/usr \
> mandir=`pwd`/debian/tmp/usr/share/man
> $(MAKE) -C doc install infodir=`pwd`/debian/tmp/usr/share/info
> dh_install --sourcedir=debian/tmp
>
> # Remove -lgpm from libaa.la
> - sed s/-lgpm// debian/aalib1-dev/usr/lib/libaa.la > \
> - debian/aalib1-dev/usr/lib/libaa.la.new
> - mv -f debian/aalib1-dev/usr/lib/libaa.la.new \
> - debian/aalib1-dev/usr/lib/libaa.la
> + sed s/-lgpm// debian/aalib1-dev$(libdir)/libaa.la > \
> + debian/aalib1-dev$(libdir)/libaa.la.new
> + mv -f debian/aalib1-dev$(libdir)/libaa.la.new \
> + debian/aalib1-dev$(libdir)/libaa.la
We have here some special handling _after_ the installation. This is typical
for the most packages. Another example is copying of files for debug
packages. Since the installation goes to libdir, we have to adapt it here
accordingly.
> dh_installchangelogs -paalib1 ChangeLog
> # Doc dir symlinks come before installdocs.
> @@ -65,7 +69,7 @@
> dh_installinfo
> # Version 1.2 is not compatable with version 1.0
> dh_makeshlibs -V 'aalib1 (>= 1.2)'
> - dh_shlibdeps -L aalib1 -l debian/aalib1/usr/lib
> + dh_shlibdeps -L aalib1 -l debian/aalib1$(libdir)
Same as above.
> dh_gencontrol
> dh_installdeb
> dh_md5sums
So I don't see how we can drop any of these changes in debian/rules using
remapping support.
If we don't want to add variables to debhelper files, we could either use the
wildcard syntax proposed by Arnd or .in files proposed by Adam. The wildcard
syntax has the disadvantage that it's sometimes not specific enough. The .in
files have the disadvantage that every package has to explicitly preprocess
them in debian/rules. The duplication of files proposed by Arnd doesn't work
at least for -dev packages since we want to support only one dev
package.
Let's summarize. I think we agree on the syntax ${field}[.${variant}] for
debian/control files. To support the lib64 'transition' we will use at least
Package.64, Desciption.64 and Provides: pkgname-${Arch} for library packages.
This can be handled by changes to dpkg-genchanges and dpkg-gencontrol as I
already did for my more specific changes. We will not duplicate dev packages,
since this will result in changes of any Debian package.
Every package that deals with a hardcoded usr/lib path having the libdir
semantic has to change the debian/rules file. Either debhelper adds support
for variables in debhelper files or every library and dev package has to
introduce .in files and preprocess them.
When Joey decides on either of these alternatives, I will adapt my patches,
so that we can restart our porting activities.
Regards,
Gerhard
Reply to: