On 06/17/2014 09:56 PM, Brian Proffitt wrote:
All:
I spoke with KB at CentOS about maintaining the qemu package for the Virt SIG.
He has expressed concerns that if oVirt curates the qemu package in order to
have the snapshotting flag turned on, then there might arise a situation where
each project within the SIG would be getting their own versions of qemu.
we just want the 'rhel version as is, compiled with an extra flag'.
if other groups the same srpm with other flags, i think should be ok
(which is different than 'use a different srpm from head'.
To help mitigate against such an occurrence, KB suggested that oVirt take
ownership of not the RHEL distro-specific version of qemu, but a more upstream
version instead. Upon discussion with Douglas Landsgraf and Itamar, it seemed
to make more sense to keep downloading from CentOS repo and rebuilding it with
flag enabled and either sharing that with the SIG or inside our own oVirt
repository.
Basically, KB's issue that if oVirt does wish to curate this package on behalf
of the SIG, that we as a project would be willing to manage all requests from
the rest of the SIG participants (such as the example he raised, which was his
personal wish that the vdi and Microsoft vpc formats be turned on as well, so
he can build Azure images more easily). If we were willing to take on such a
responsibility for the SIG, then this would mitigate multiple versions of qemu
appearing.
From my side, I believe this is a reasonable expectation, given that we are
going to get what we need within CentOS and still can be a responsible
community player within the SIG.
I put the question to the developers: is this something we want to undertake,
or should we simply maintain our version of qemu within an oVirt-specific
repository?
I see two variants here:
1. RHEL proper SRPM, where the only change is how its built wrt
flags/configuration allowing more than what RHEL comes with out of the
box (would cover vpc format if just a flag).
will not cover special backports not going through rhel proper.
2. future/next/head/latest SRPM, based on an upstream qemu stable
version rpm (or maybe the fedora virt-preview one is more likely).
one would be 'stable', the other 'updates-testing' or 'virt-preview'.
_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
