Re: dpkg and debhelper patches for lib64 support
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
> IMHO, the first one is more intuitive, at least for the lib64 problem.
> Your linux-wlan-ng-modules example could then be expressed
> as:
>
> Package: linux-wlan-ng
> Architecture: i386 powerpc arm alpha hppa
> Description: utilities for wireless prism2 cards
>
> Package: linux-wlan-ng-modules-${kvers}
> Architecture: none
> Architecture.modules: i386 powerpc arm alpha hppa
> Provides: linux-wlan-ng-0.2.0-modules
> Description: drivers for wireless prism2 cards
>
> 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.
> If you want to avoid variable substitution in the debhelper files, the
> obvious alternative is to duplicate those files, e.g. put /usr/lib in
> debian/libfoo.dirs and /usr/lib64 in debian/lib64foo.dirs (or maybe
> debian/libfoo.64.dirs). For the debian/*.files files, this can often be
> avoided with wildcards, e.g. converting /usr/lib/lib*.so.* to
> /usr/lib*/lib*.so.*.
debian/files.in -> debian/files
debian/files.in -> debian/files64
If you really want to avoid duplication.
Reply to: