[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [stage1-xen PATCH v1 09/10] build/fedora: Add `RUNNING_STAGE1_XEN.md`



On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
> On Thu, Sep 07 2017 at 12:44:16 AM, Stefano Stabellini 
> <sstabellini@xxxxxxxxxx> wrote:
> 
> [...]
> 
> >> +[root@localhost ~]# ls /opt
> >> +qemu-unstable  stage1-xen  xen-unstable  xen-unstable-runit
> >> +```
> >> +
> >> +This will extract all the build artifacts into `/opt` directory.
> >
> > Is there a reason to keep all the binaries under /opt? I mean, at this
> > point, we could do something like
> >
> >   cp -ar /opt/xen-unstable/* /
> >
> > and do the same for the other components.
> 
> Yes, we can do that, but I feel its a good idea. :-)
> 
> Outside of specific paths (such as /var or /etc), its better to let RPM
> manage files in the / hierarchy. That way rpm -qf can return sensible
> results when we need to login and debug issues.
> 
> > Do we keep them under /opt for ease of management, so that the next time
> > we do a build, we can easily test with a different Xen version? Or is
> > there another reason?
> 
> That's correct. Keeping things isolated in /opt lets us test different
> versions of xen during development. In production we can use the same
> approach to support multiple versions of xen and do rolling updates or
> rollbacks.
> 
> Btw, I should point out that this is not something new. NixOS has been
> using the approach of building packages in separate filesystem hierarchy
> for a while now.
> 
> We are just selectively adopting their ideas.

That's OK for me. Please add a few words on this in the commit message.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.