Hi,
currently virt-builder's index contains only x86_64/amd64 images, so
asking virt-builder to produce an image always produce a x86_64 image,
regardless of the host. This also mean that trying to produce, say, a
new fedora-20 image from an i686 not only would produce an unexpected
result, but also would prevent to e.g. install packages on it.
So virt-builder and its index need to be able to distinguish the
architecture; choosing the architecture could be a --arch parameter for
virt-builder, but what about the keys in the index since it needs to
preserve compatibility with former versions?
Maybe a solution could be:
a) adding arch=.. keys in entries
b) rename (or just copy, to avoid breaking older virt-builders) keys to
$distro-$version-$arch
c) to not break compatibility with user input virt-builder joins
$user_selection + $arch = $user_selection-$arch, and looks in the
index
d) default $arch to `uname -m/p`, if --arch is not specified
Or maybe an even idea could be to give the index file a suffix with the
architecture name... although that could break users specifying an
absolute URL for an own index of distros...
Also, two side notes related to the "different architecture handling"
issue:
1) the naming of architectures can change between distros (e.g. amd64 vs
x86_64 vs x64, powerpc vs ppc) -- a simple hardcoded mapping in
virt-builder should do the job, I guess?
2) what should be done with commands/operations (e.g. --install) that
try to run stuff from the guest, when the host and guest
architectures are different? Always deny, deny but allow with a
configure switch, or don't bother and let the user get their failure?
--
Pino Toscano