Re: dpkg and debhelper patches for lib64 support
On Monday 16 June 2003 23:52, you wrote:
> > 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.
>
If this is really an issue, we could also add this information to the
existing information, e.g. "the package installs to /usr/lib64 on 64 bit
platforms".
> > 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.
>
Right, my design point is reducing the complexity for the maintainer,
especially avoiding redundancy.
> 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.
Duplicating these files means a lot of redundancy and maintenance complexity.
We have experimented with some heuristics to transform the files, but since
not every lib has to be transformed to lib64, but only those that are related
to the configure option --libdir, it seems to be impossible to find a generic
transformation.
>
> --- 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.
>
I agree, that's a good idea.
> @@ -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.
>
Again, I think, this creates a lot of redundancy, since 99 per cent of the
information of both packages are identical. If we add another copy for the 64
bit package, it is open how to name the Architecture for the 64 bit as well
as for the 32 bit variant.
> 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.
>
That's exactly what I tried first without any success. I don't understand why
it is a hack. /usr/lib is just substituted by a variable $(libdir) and lib by
$(libname).
> 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.
This should of course be done more generic, but it's only a sample
implementation...
>
> 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?
I am working on it. The basic idea is to use variables as well, and
preprocess the files by debhelper.
Reply to: