I like this idea. It has reach.
Adam Heath wrote:
> Package: xlibs
> Package.athlon: xlibs-athlon
> Depends.any: coreutils
> Depends: libgcc1
> Depends.athlon: libathlon_gcc1
> Architecture: any
> Architecture.athlon: x86-64
So then it would look something like this for a generic lib package:
Package: libfoo1
Package.64: lib64foo1
Depends: ${shlib:Depends}
Architecture: any
Description: the foo library
The foo library for all your bar needs.
Description.64: the 64 bit foo library
The foo library for all your 64 bit bar needs.
If you need to run 32 bit foo programs, install libfoo1.
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.
> 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.
That said, could the .any field merge short and extended descriptions?
Package: libfoo1
Package.64 lib64foo1
Description.any: the foo library
The foo library for all your bar needs.
Description.64: (64 bit version)
.
This is a 64 bit version of the library. If you need to run 32 bit
foo programs, install libfoo1.
Yeilding:
Package: libfoo1
Descrption: the foo library
The foo library for all your bar needs.
Package: lib64foo1
Description: the foo library (64 bit version)
The foo library for all your bar needs.
.
This is a 64 bit version of the library. If you need to run 32 bit
foo programs, install libfoo1.
This might be asking too much.
> Additionally, this support is really simple to do, and could be done with
> dpkg-gencontrol, or even some preprocessing magic that reads control.in.
Remember that dpkg-genchanges will also need to take this into account in
its debian/cpntrol parsing. See bug #150597.
I'd hope we could avoid templates once we get past prototyping[2], as they're
just kinda gross. Anyway, I hope this new mechanism will do away with
a whole class of existing control file templates: the ones used for kernel
module packages.
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.
I have not figured out what would keep it from building the
linux-wlan-ng package when the subfield is set. Maybe there would be a
way to set the subfield from inside the rules file, so I use them in
both stanzas:
Package.normal: linux-wlan-ng
Architecture.normal: i386 powerpc arm alpha hppa
Description.normal: 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
binary:
if $(BUILDING_KERNEL_MODULES); then
dpkg-setsubfield modules
else
dpkg-setsubfield normal
fi
But this would not work unless dpkg-genchanges stopped parsing the
control file too -- otherwise it would find no packages to put in the
changes file!
--
see shy jo
[1] It needs a better name.
[2] Now I can't stop thinking about C++.
Attachment:
pgp1QluAM0lHA.pgp
Description: PGP signature