[libvirt] daemon: Install libvirtd under 'bin' not 'sbin'
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org> This binary is not admin-only at all and launching it as normal user is a supported use case: session. --- daemon/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index fbb0ae1..472e523 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -70,7 +70,7 @@ if WITH_LIBVIRTD man8_MANS = libvirtd.8 -sbin_PROGRAMS = libvirtd +bin_PROGRAMS = libvirtd confdir = $(sysconfdir)/libvirt/ conf_DATA = libvirtd.conf -- 1.7.10.2
On Thu, Jun 7, 2012 at 3:31 PM, Zeeshan Ali (Khattak) <zeeshanak@gnome.org> wrote:
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org>
This binary is not admin-only at all and launching it as normal user is a supported use case: session.
I know it may be controversial, but I give my ack anyway ;) regards -- Marc-André Lureau
On Thu, Jun 7, 2012 at 3:39 PM, Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
On Thu, Jun 7, 2012 at 3:31 PM, Zeeshan Ali (Khattak) <zeeshanak@gnome.org> wrote:
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org>
This binary is not admin-only at all and launching it as normal user is a supported use case: session.
You may also want to move the man page from section 8 (admin) to 1. -- Marc-André Lureau
On Thu, Jun 7, 2012 at 3:40 PM, Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
This binary is not admin-only at all and launching it as normal user is a supported use case: session.
You may also want to move the man page from section 8 (admin) to 1.
You also need to update remote/remote_driver.c SBINDIR "/libvirtd" and friend -- Marc-André Lureau
On 06/07/2012 07:31 AM, Zeeshan Ali (Khattak) wrote:
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org>
This binary is not admin-only at all and launching it as normal user is a supported use case: session.
The idea makes sense to me, but as the other followups mentioned, you'll need a v2 that scrubs the rest of the source to find it in the correct locations before we can apply it. Not mentioned so far is that libvirt.spec.in will need modification, as will daemon/libvirtd.service.in. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 06/07/2012 11:13 AM, Eric Blake wrote:
On 06/07/2012 07:31 AM, Zeeshan Ali (Khattak) wrote:
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org>
This binary is not admin-only at all and launching it as normal user is a supported use case: session.
The idea makes sense to me, but as the other followups mentioned, you'll need a v2 that scrubs the rest of the source to find it in the correct locations before we can apply it. Not mentioned so far is that libvirt.spec.in will need modification, as will daemon/libvirtd.service.in.
Oh, and if it isn't clear, the spec changes must be such that F17 and RHEL 6 still install to /sbin, leaving only F18 and RHEL 7 as the first releases that could support /bin (this probably means manually moving things around according to conditionals). Probably means you also have your work cut out for './autogen.sh --system' doing the right thing across platforms. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Thu, Jun 07, 2012 at 11:42:53AM -0600, Eric Blake wrote:
On 06/07/2012 11:13 AM, Eric Blake wrote:
On 06/07/2012 07:31 AM, Zeeshan Ali (Khattak) wrote:
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org>
This binary is not admin-only at all and launching it as normal user is a supported use case: session.
The idea makes sense to me, but as the other followups mentioned, you'll need a v2 that scrubs the rest of the source to find it in the correct locations before we can apply it. Not mentioned so far is that libvirt.spec.in will need modification, as will daemon/libvirtd.service.in.
Oh, and if it isn't clear, the spec changes must be such that F17 and RHEL 6 still install to /sbin, leaving only F18 and RHEL 7 as the first releases that could support /bin (this probably means manually moving things around according to conditionals). Probably means you also have your work cut out for './autogen.sh --system' doing the right thing across platforms.
Having to maintain two different install locations, means the move to /usr/bin is just going to cause us pain for no real gain, further suggesting we just don't do this. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Jun 07, 2012 at 04:31:14PM +0300, Zeeshan Ali (Khattak) wrote:
From: "Zeeshan Ali (Khattak)" <zeeshanak@gnome.org>
This binary is not admin-only at all and launching it as normal user is a supported use case: session.
While running it as a normal user is supported, users should never need to launch it themselves, unless troubleshooting some problem. libvirt will always auto-start the session daemon, which in fact would argue for /usr/libexec, not /usr/bin. So IMHO, we should just leave it where it already is, in /usr/sbin. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (4)
-
Daniel P. Berrange -
Eric Blake -
Marc-André Lureau -
Zeeshan Ali (Khattak)