Re: dpkg and debhelper patches for lib64 support
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 18 June 2003 04:26, Joey Hess wrote:
> Package: libfoo-dev
> Package.64: lib64foo-dev
> Architecture: any
> Depends: libfoo1
> Depends.64: lib64foo1
> Conflicts.64: libfoo-dev
> Description: the foo library development files
> Development files for the foo library.
> Description.64: the 64 bit foo library development files
> Development files for the 64 bit foo library.
> .
> If you need to build 32 bit programs using foo, install libfoo-dev
> instead. Currently that package cannot be installed at the same time as
> this one.
I don't think this is doable for -dev packages because it would mean
having to change practically all build-depends in all packages. We can't
get around touching the library packages, but whatever solution we find
should work without changing the package source of the majority of
the existing packages on new 64 bit architectures.
> > A user compiling the package can choose the default, or can choose to
> > compile for athlon.
>
> There will need to be a way to set the default subfield[1] on a per arch
> basis, because I think the x86-64 arch will want to default to using the
> .64 fields.
>
> > When generating an output field, the variant of the field is choosen. If
> > one isn't found, then the standard field is used. Additionally, .any
> > fields are merged in with whatever field is choosen.
>
> I'm ambivilant about this any thing, and I note it has to magically add
> the right delimiters when merging fields -- ", " for relationship and
> architecture fields, " " for descriptions, and presumably no delimiters
> for other fields.
I'd try to keep the complexity as low as possible here. If you do any
concatenation here, it is guaranteed to confuse people. When there is
a specialized version for one field, just ignore the generic one.
Also, don't have subfields with a predefined meaning like defaulting
to .64 for amd64. We can have some conventions, but the specific
fields should be selected by debian/rules, not by some magic.
> Package: linux-wlan-ng
> Architecture: i386 powerpc arm alpha hppa
> Description: utilities for wireless prism2 cards
>
> Package.modules: linux-wlan-ng-modules-${kvers}
> Architecture.modules: i386 powerpc arm alpha hppa
> Provides.modules: linux-wlan-ng-0.2.0-modules
> Description.modules: drivers for wireless prism2 cards
>
> Here if it's building the kernel modules it sets the subfield to
> "modules", and sets kvers in substvars. For a normal build it doesn't
> build modules, but just the linux-wlan-ng package. I'm assuming that the
> dpkg tools would be smart enough to ignore the second stanza if the
> subfield is not set. If not I'd have to remove the blank line between
> the stanzas, which would be uglier.
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.
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.
On Wednesday 18 June 2003 00:32, Joey Hess wrote:
> It's my understanding that directory remapping (and discarding) is
> already slated for dpkg 2.0. I don't know at what stage its design is,
> but all that's needed I think is to add an architecture field to that
> design, to make a given remapping only apply to packages from a given
> architecture.
>
> Doesn't this avoid the entire need for complicated substitutions in
> debian/rules and debhelper files?
No, that won't work. For example, we want some packages to actually
install something to /usr/lib and to /usr/lib64. The substitutions in
debian/rules are actually quite straightforward and there are few of them.
Remapping /usr/lib in any way sounds like a guarantee for trouble
and we should not rely on this mechanism for regular packages.
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.*.
Arnd <><
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+8Ozd5t5GS2LDRf4RAi//AJ9Rwjv5zTa6Y0XoCNd0eKTPlEaXbQCfWNzB
GyUsDWHoIKhmfVrj+fCIVqE=
=1gsg
-----END PGP SIGNATURE-----
Reply to: