|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH] ioemu: Fixes for build/install system
Christoph Egger writes ("[Xen-devel] Re: [PATCH] ioemu: Fixes for build/install
system"):
> install-doc: $(DOCS)
> - mkdir -p "$(DESTDIR)$(docdir)"
> - $(INSTALL) -m 644 qemu-doc.html qemu-tech.html "$(DESTDIR)$(docdir)"
> + $(INSTALL_DIR) "$(DESTDIR)$(docdir)"
> + $(INSTALL_DATA) qemu-doc.html qemu-tech.html "$(DESTDIR)$(docdir)"
> ifndef CONFIG_WIN32
> - mkdir -p "$(DESTDIR)$(mandir)/man1"
> - $(INSTALL) -m 644 qemu.1 qemu-img.1 "$(DESTDIR)$(mandir)/man1"
> - mkdir -p "$(DESTDIR)$(mandir)/man8"
> - $(INSTALL) -m 644 qemu-nbd.8 "$(DESTDIR)$(mandir)/man8"
> + $(INSTALL_DIR) "$(DESTDIR)$(MAN1DIR)"
> + $(INSTALL_DATA) qemu.1 qemu-img.1 "$(DESTDIR)$(MAN1DIR)"
> + $(INSTALL_DIR) "$(DESTDIR)$(MAN8DIR)"
> + $(INSTALL_DATA) qemu-nbd.8 "$(DESTDIR)$(MAN8DIR)"
Once again, these are changes to code from upstream. I see that this
change has been applied upstream. Please try to avoid submitting
changes for inclusion both in upstream and in qemu-xen-unstable. That
causes trouble when I pull. If there is a compelling reason why
the change should be included in Xen before we get it via upstream in
the usual course of events, then we might relax this rule but you
should mention this fact and give an explanation.
In this case the upstream change comes too late to be included in 3.4
- it is (quite correctly) only on the upstream main branch, not on the
upstream stable branch.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|