[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg and debhelper patches for lib64 support



Gerhard Tonn wrote:
> Runtime packages for a 64 bit platform that install to lib64 are 
> installable concurrently with their counterparts on the respective 32 
> bit platform, e.g. amd64 and i386 or s390x and s390. This is achieved by 
> naming the 64 bit package differently from the 32 bit package, e.g. 
> lib64ncurses5 and libncurses5.

I notice that your implementation makes such packages have identical
descriptions as their 32 bit brethren. I think that is a bad idea. All
available packages on any given arch should have unique descriptions,
that explain what they contain; for 64 bit lib packages that would
include a note that they're 64 bit.

> A new keyword Package64 is supported in debian/control. It describes the 
> package name of a given package on a 64 bit platform.
> 
> A new keyword Substvarname is supported in debian/control. It describes the 
> name of a substitution variable used elsewhere in the control file, e.g. to 
> specify dependencies. Its value is the package name. If the keyword is 
> missing the variable name is derived from the package name.

This is a lot of additional complexity intorudced apparently to keep the
changes as small as you can. I don't think this is a good idea.

Since I maintain aalib, I'll use your patch to that as an example.

--- aalib-1.4p5/debian/aalib1.install   2003-06-08 15:11:51.0000000000000
+++ aalib-1.4p5.new/debian/aalib1.install       2003-06-08 15:10:11.000000000 +0000
@@ -1,2 +1,2 @@
-usr/lib/libaa.so.1.*
-usr/lib/libaa.so.1
+./${libdir}/libaa.so.1.*
+./${libdir}/libaa.so.1

This turns something that was simple, straightforward, and data-driven
into something that's incomprehensible without reading another file and
looking at the output of a program. I would rather maintain two varients
of this file, or run some program after the fact to move the installed
library files around.

--- aalib-1.4p5/debian/control  2003-06-08 15:11:51.000000000 +0000
+++ aalib-1.4p5.new/debian/control      2003-06-08 15:11:13.000000000 +0000
@@ -8,7 +8,7 @@
 Package: aalib1-dev
 Architecture: any
 Section: devel
-Depends: aalib1 (>= 1.2-18), xlibs-dev, slang1-dev (>> 1.3.0-0), libncurses5-dev, ${misc:Depends}
+Depends: ${aalib1} (>= 1.2-18), xlibs-dev, slang1-dev (>> 1.3.0-0), libncurses5-dev, ${misc:Depends}

The ${aalib1} is gross. I'd prefer something like a dependency on
aalib1-${architecture}, which is provided with apprioriate substitutions
by the library packages. Although that's kinda gross too, and I don't know
if I agree with your assumption that it's ok to make the -dev packages have
the same name and require a user be root to decide which width library they
can link with. Having a separate aalib1-64-dev created in a separate stanza
perhaps.

@@ -18,6 +18,7 @@
  development, plus developer's documentation.
 
 Package: aalib1
+Package64: lib64aalib1
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: ascii art library

I would rather maintain a separate copy of this stanza for the 64 bit
package. This would also let me give it a useful description.

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)
+
..
-       dh_installdirs usr/lib usr/include
+       dh_installdirs usr/$(libname) usr/include

Here we see the debhelper hack just break down, with command-line
arguments having to be manually hacked up instead. The rest of the rules
file patches are downhill from here and just highlight for me that it
would be cleaner to not make these changes and have a utility that went
through at the end and moved everything around.

Or -- here's an idea -- make dpkg remap the locatons of libraries from
specially flagged 64 bit packages at install time based on a config
file. If that were done right the same config file could allow for the
often-requested feature of /dev/nulling /usr/share/doc and other
directories. Something like:

arch	orig-directory	map-to
x86-64	/usr/lib	/usr/lib64
386	/usr/share/doc	# discard

> The debhelper scripts understand now the variables ${libname} and ${libdir} 
> in *.files, *.links, *.dirs and *.install files.

This is not the first request I've received for debhelper to expand
variables in files, and I have not done it for the kind of reasons I
gave above. If I ever did do it I would probably want it to be done as
generally as possible, and not in the very specific way the patch does
it. But I would much prefer not to do it at all.

Of course I cannot even do anything about adding this support to
debhelper until dpkg is modified.

Also, how _do_ you plan to deal with postinst scripts that have /usr/lib
in them, and with shlibs files?

-- 
see shy jo

Attachment: pgpGUBro1jI4f.pgp
Description: PGP signature


Reply to: