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:
pgpRBXyHIRk1S.pgp
Description: PGP signature