Re: dpkg and debhelper patches for lib64 support
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 16 June 2003 23:52, Joey Hess wrote:
> Gerhard Tonn wrote:
> 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.
That makes sense. OTOH, that would mean adding the sentence 'This
is the 64 bit version of the library' to every library package even for
systems that don't have any 32 bit packages installed. Is the 'unique
description' requirement part of the policy?
> --- 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.
We hadn't thought of that. Agreed, that would be a lot better, it will even
make it easy to build-depend on installing some package for the
native architecture when it does not come from the same source.
Note that since you cannot have versioned depends and provides for
one package, it will have to be more like (ignoring the Package64
question for now):
Package: aalib1
Provides: aalib1-${Arch}
Package: aalib1-dev
Depends: aalib1-${Arch}
Conflicts: aalib1 (<< ${Source-Version}), lib64aalib1 (<< ${Source-Version})
> 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.
The question of -dev packages is the hardest, since they have both
architecture dependant and architecture independant files in them.
Suppose you want to have these files:
a) /usr/lib/libfoo.so
b) /usr/lib/libfoo.a
c) /usr/lib64/libfoo.so
d) /usr/lib64/libfoo.a
e) /usr/include/foo.h
The regular packages currently contain a, b and e. The logical choice
for the 64 bit package is c, d and e, but that would conflict because
you can't install e twice. One solution is to create a new package
libfoo-headers for every library, which means a lot of restructuring.
Currently, the idea to handle it is keeping libfoo-dev for 32 bit as it
is and making the 64 bit version contain a, b, /c/ and e. It is relatively
simple to do and it will allow you to link dynamic 32 bit binaries on
64 bit systems, but not static ones.
> @@ -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.
Then what do you want to put in the Architecture: field? Should we have
something like 'Architecture: anylib64' or do you have something different
in mind?
> 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
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...
> > 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.
The first attempt was to preprocess those files, replacing lib with lib64
based on some heuristics, but that soon got really ugly. I agree that
it should be more generic than the current patch, but I don't really
see a way around using variables somewhere for dh_install and friends.
Arnd <><
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+7lmE5t5GS2LDRf4RAt6qAJsF1Q6LUHrQouYCgLhgcEnJ0cy7zgCdG5Hl
bddAqJFcifarxye8/YhC41c=
=XqgS
-----END PGP SIGNATURE-----
Reply to: