Re: Strategy for running BuildStream on RHEL 7.x?

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Mon, 2017-07-31 at 15:53 +0100, Sam Thursfield wrote:
> On 30/07/17 15:05, Justin Erenkrantz wrote:
> > The upcoming RHEL 7.4 is expected to introduce official flatpak support.
> > The latest public beta for 7.4 has OSTree 2017.5-3 and flatpak 0.8.5-2.
> > Yet, I believe that it is missing bubblewrap.
>
> I'm pretty confused how that would work ... flatpak is totally tied to 
> bubblewrap. Perhaps they have bundled bubblewrap into the flatpak package?
>
> It wouldn't be impossible for us to do the same as bubblewrap is pretty 
> simple to build,

Flatpak includes bubblewrap as a git submodule and builds itself a
little hybrid helper program.

> > Additionally, Python 3 is not distributed as part of RHEL proper - yet, it
> > is part of Software Collections via rh-python35 (or rh-python34):
> >
> > https://www.softwarecollections.org/en/scls/rhscl/rh-python35/
> >
> > pygobject isn't included in rh-python35.  When trying to build that via pip
> > on RHEL 7.4 with rh-python35, it leads to basically needing the full GNOME
> > stack locally....which, if I had BuildStream, might be a tractable problem,
> > but...well, turtles.
> >
> > Thoughts?  Could we perhaps leverage Flatpak/OSTree itself to distribute a
> > version of BuildStream that would work on RHEL 7?  Or, do we have to treat
> > RHEL 7 as an ancient Linux distro that doesn't support bubblewrap and
> > sandboxing?  I'd hate to miss out on the OSTree advantages there.  Or??
>
> That's an issue indeed.
>
> It might be possible to rewrite the ostree backend to call the `ostree` 
> CLI rather than pygobject. That would be an ugly thing to do in 
> principle, but if it looks like it'd work then maybe it's a practical 
> solution.
>
> I don't know if `pip install pygobject` can actually be trusted; but 
> building pygobject from source isn't too tricky, gobject-introspection 
> devel headers and python devel headers are needed (and should be 
> available in RHEL) and that's about it.

I should note that ostree itself requires glib (with or without
introspection), and beyond glib, the introspection data for ostree and
pygobject itself there are no other GNOME specific dependencies (in
other words, I would hardly call this "pulling in the whole GNOME
stack").

I'm not sure what to do for RHEL 7, if they are adamant about not
including an suid bubblewrap (or even a non-suid bubblewrap) then I
suppose we could try looking into a linux-user-chroot solution (not
sure, is it worth going this far for RHEL 7 ?).

Note that some distros have bubblewrap non-suid and instead require
that the OS allow regular users to create namespaces and drop
priviledges.

Cheers,
    -Tristan