Here are three packages, none of them using %{?_isa} in their spec files:
(a) libvirt http://pkgs.fedoraproject.org/cgit/rpms/libvirt.git/tree/libvirt.spec
(b) libguestfs http://pkgs.fedoraproject.org/cgit/rpms/libguestfs.git/tree/libguestfs.spec
(c) qemu http://pkgs.fedoraproject.org/cgit/rpms/qemu.git/tree/qemu.spec
They all have a "core" package, and subpackages which Require this
core package, for example:
%package system-x86 # subpackage of qemu
Summary: QEMU system emulator for x86
Group: Development/Tools
Requires: %{name}-common = %{epoch}:%{version}-%{release}
...
%package client # subpackage of libvirt
Summary: Client side utilities of the libvirt library
Group: Development/Libraries
Requires: %{name}-libs = %{version}-%{release}
...
The question has been asked, do any of these need to be modified to
use the _isa macro, eg:
Requires: %{name}-libs%{?_isa} = %{version}-%{release}
I believe the answer is:
(1) YES for the two libraries (a) and (b)
(2) NO for qemu (c) because it's a program not a library
However I'm not sure I can clearly express why this is true. AFAIK it
has never caused any problems not using %{?_isa}.
But wait! There's more ...
We're about to modularize parts of the qemu binary into plugins, one
for each block driver.
(https://bugzilla.redhat.com/show_bug.cgi?id=1393688) The aim of this
is to reduce the dependencies of qemu.
The qemu plugins are shared libraries, eg. %{_libdir}/qemu/block-iscsi.so
and (eg) the x86_64 plugin cannot be plugged into an i686 qemu binary
or vice versa.
Is this a case where we should use %{?_isa} in qemu.spec?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
