On Sun, Apr 26, 2009 at 08:09:28AM +0200, Kevin Kofler wrote: > Matthew Woehlke wrote: > > Our requirements are that one build environment produces one package > > containing both 32- and 64-bit binaries. > > If you're talking about RPM packages, that's completely broken, an x86_64 > RPM is supposed to only contain x86_64 stuff (and it won't install on > 32-bit systems), and an i386 RPM definitely must not contain 64-bit stuff. I think it's interesting that three things: (1) cross-compilation, (2) virtualization and (3) Wine [which is a type of virt] becoming usable, have all happened at around the same time, and I don't think it's a coincidence. It means what you said above isn't really true any more, or more circumspectly, if what you said is true, then RPM isn't designed for this new world. Some examples: Since Wine reached 1.0 a few years ago and became usable, it now becomes practical to build and test software on Fedora. Hence the Windows cross-compiler project. "noarch" RPMs contain Windows libraries. With virtualization now commonplace, you can no longer assume that the architecture you build on will be the architecture you run on. It's quite possible, in fact desirable, to store programs in an RPM of a different architecture, that will run in (eg) qemu. An example of this is virt-p2v and the V2V tools, where we store drivers for all sorts of different platforms and architectures inside the RPM. With appliances, it's quite desirable to want a 32 bit appliance stored alongside a 64 bit program. 32 bit appliances are generally better because of the qualities of appliances: They run in a VM, so host architecture doesn't matter. They run in very little memory, so 64 bit isn't useful. You want them to be as small as possible, and (sometimes, not always) 32 bit binaries are smaller. In the actual appliances cases I'm looking at now, we really want to mix not just 32 and 64 bit, but all combinations of architectures, such as having x86-64 library linked with a (eg) ppc32 appliance. [I should also add as a note here that I'm not talking about binary blobs, firmware etc. All of the above cases are built from source.] Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
