Re: dpkg and debhelper patches for lib64 support
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 19 June 2003 01:21, Adam Heath wrote:
> On Thu, 19 Jun 2003, Arnd Bergmann wrote:
> > What you're proposing here is a very different approach to the
> > one you outlined above. Instead of changing the value of some
> > fields, this builds a binary package or skips it conditionally based
> > on a definition. Either way can be used to solve the problem
> > but we should decide for one of them instead of supporting both.
>
> Well, it's been slightly discussed to support #ifdef like functionality,
> and comments, in debian/control
AFAICS, when we have #ifdef in debian/control, there would be
no need for 'Package.64:' any more:
%if ! ${lib64_arch}
Package: libfoo1
%else
Package: lib64foo1
%endif
Architecture: any
Description: base libraries for the bar project
The foo1 library provides foo to bar applications
%if ${lib64_arch}
.
This is the 64 bit version of libfoo1.
%endif
(Yes, that is roughly what rpm 4 does.)
> > When the 'modules' subfield is selected, the modules are built,
> > otherwise, it will be skipped because of the default 'Architecture:'
> > value.
>
> This is special casing the processing based on the value of a field. This
> is not how things are going to be done.
ok.
> debian/files.in -> debian/files
> debian/files.in -> debian/files64
>
> If you really want to avoid duplication.
When debian/files is already preprocessed, why not always do
debian/files.in -> debian/files ?
Arnd <><
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+8X2e5t5GS2LDRf4RApvJAJ9iR0pvqGW8PQmiVTiaB/R25ZagPACfaZ2s
+uVDQG0EMeCRiEJMm2tPtDo=
=qJ3m
-----END PGP SIGNATURE-----
Reply to: