On 10/31/2012 09:42 PM, Laine Stump wrote:
On 10/30/2012 05:35 PM, Gene Czarcinski wrote:
About being compatible with old code. I see the dhcp6 patches and
this potential patch as being based on v1.0.0 and not being
back-ported. So I am not sure I see a potential conflict.
Being able to backport patches to older libvirt releases is not the
issue we are concerned about - that is actually usually not an important
consideration. What *is* important is the ability to build and run the
new libvirt releases on older platforms. For example, if the upstream
release containing your patches were built on CentOS6.3 or RHEL6.3, the
dhcp6 functionality wouldn't be available, because those distros are
stuck at dnsmasq-2.48. That's okay as long as all the pre-existing
functionality still works properly on those distros. Eliminating radvd
in favor of using dnsmasq for ipv6 ra and autoconf would *not* be
acceptable, though, because if the release containing that patch were
built on RHEL6/CentOS6, it would mean a regression in behavior, since
IPv6 autoconf/ra would cease to work.
Lets see if I understand what you are saying correctly.
You want to be able to a specific adaptation/configuration of
libvirt-1.0.0 on RHEL6/CentOS6 but not insist that their dnsmasq be
updated.
Doing some looking, it appears that RHEL6.3 uses libvirt-0.8.7 and
CentOS6.3 uses libvirt-0.9.10. I can see some group wanting to remain
on there particular vintage of RHEL or CentOS and to want the latest
libvirt at the same time. OK, but why not require some other packages
(such as dnsmasq) be updated also.
Are these same folks contemplating putting a newer kernel such as
kernel-3.6.3-1.fc17.x86_64 also?
I thought the whole idea with RHEL and CentOS was stability and
"guaranteed" long term (5 years) support. If you want to run the latest
and greatest, then RHEL and CentOS are not the answer for you.
Gene
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list