On Mon, Mar 19, 2012 at 11:22:26AM -0500, Anthony Liguori wrote: > On 03/19/2012 11:20 AM, Eduardo Habkost wrote: > >On Mon, Mar 19, 2012 at 05:13:22PM +0100, Paolo Bonzini wrote: > >>Il 19/03/2012 16:43, Eduardo Habkost ha scritto: > >>>>No, I'm not suggesting --package-name, I'm suggesting that qemu-kvm > >>>>would carry a patch to configure that changed a fixed PACKAGE_NAME > >>>>define. > >>> > >>>Are you really suggesting that forcing downstream to carry a patch is > >>>better than having a configure option? > >> > >>Not downstream as in RHEL; downstream as in qemu-kvm which is a fork anyway. > >> > >>>If you suggest making it configurable using a variable on the 'make' > >>>command-line it would be OK, but I kind of hoped that no modern software > >>>project would ever require packagers to use configure-by-sed methods to > >>>set build parameters. > >> > >>I think the package name is a pretty special case. Even with autotools, > >>it's pretty much the only thing that requires configure-by-sed to change it. > > > >I still don't understand why, except that it's a limitation of the build > >system implementation. If we don't have that restriction, I don't see > >why this should be restricted by design. > > Because rebranding QEMU is not something we want to actively > encourage downstreams to do. The fact that qemu-kvm does this is a > historical artifact that we'll hopefully kill off in the near future.
I don't think this will ever be killed. Note that this has nothing to do with the fact that qemu-kvm is a separate upstream tree, but with build-time options. The problem is: - RHEL provides Qemu, but only with the build options we support; - I want to avoid conflicting with third-party packages (read: the qemu package on EPEL) that use different build options. The main difference happens to be the fact that we build only qemu-kvm, but there are all other build-time options we enable/disable and that may be chosen differently by a third-party Qemu package. The purpose of this is not rebranding, it's storing binaries, data, and configuration files in separate places to avoid unnecessary conflicts and pain for the user. -- Eduardo
