Re: GNOME Build situation and BuildStream

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

Hi Christian,

On Tue, 2017-04-25 at 10:07 -0700, Christian Hergert wrote:
> On 04/25/2017 09:38 AM, Tristan Van Berkom wrote:
> > Any questions about what we have created so far and how it works ?
> > Please
> > reply and ask about these !
>
> I don't think this was mentioned, apologies if I missed it.

No worries, apparently it was a very long email :)

> One thing we want in Builder is a simulator. Being able to take a
> BuildStream bootable image and overlay the project is a very
> desirable
> feature. It could be a patched gnome-shell, glib, or an application.
> It
> would be great If your "workspace" feature can allow us to do this on
> the developer host rather quickly (so we don't wait minutes to launch
> the simulator).

Reducing the image creation routine from minutes to seconds is a bit
difficult, for that purpose you might try reusing an already made image
across multiple sessions.

The way this would normally work (without customization):

  o The user downloads or builds artifacts for all modules which go
    into the image (where 'artifact' is the output of a traditional
    `make DESTDIR=${artifact-root} install`).

    A build is only performed in the case that an artifact does not
    already exist.

  o The user can now build a "workspace" module on pre-built
    dependencies

  o The user can now create an image using their "workspace" artifact

  o The image is then created using all the required artifacts, this
    is an I/O bound task which takes time, proportional to the size of
    the image

The user story for the above should just only be a matter of:

  o Creating a workspace (something like `bst workspace <modulename>`)
  o Edit sources in the workspace
  o Running `bst build gnome-system-image.bst` would now take the
    active workspace into account

But this would take minutes...

So instead, for a really nifty Builder simulator feature, you might
prefer to work with the content of the image and have it cooperate with
Builder's simulator use case; which may mean either Builder has a fork
of upstream release modulesets (with only few changes), or that the
upstream modulesets have some kind of support for this built in.

There are probably a few ways to get this to be lightning fast once you
have some cooperation from the already created image, here is one idea:

  o You have the image created with a kernel with virtualization
    features, specifically you will want the 9p 'virtfs' filesys.

  o You have the initramfs `init` script check for the presence
    of the 9p device and mount it if it's there (this is where you
    will have the build output "prefix" of only the modules you want
    overridden, which are already staged on the host filesys).

  o You ensure that the system ld.so.conf is configured in such
    a way that the mounted virtfs 'libdir' location takes precedence,
    and probably run ldconfig (not sure that's needed).

    This would ensure that a rebuilt 'glib' is the effective glib
    for the whole system's boot sequence

  o Something similar needs to be done for core system applications
    like gnome-control-center or the like, to ensure the execs in the
    thing you've mounted take precedence over the copies in the image.

    Probably you dont want to care about gdm, gnome-keyring and system
    services, from a Builder perspective.

Something along those lines would allow you to reuse the same image
across multiple Builder user sessions and always be able to rebuild
something against existing pre-built dependencies, and boot an image
immediately after the build completes.

> For the application case, we certainly just want to inject the
> Flatpak'd
> build of the app from Builder rather than a traditional build.
>
> As you can imagine, it would be hell if we had users downloading full
> bootable images regularly. Do you anticipate a way to publicly expose
> the OStree even for bootable images? Would it be reasonable for
> Builder
> to use that to keep things in sync?

> From the BuildStream maintenance perspective I much prefer to keep the
artifact caching implementation details a "black box" (I want to keep
the door open for later supporting other OSes than only Linux).

However it should be easy enough to have BuildStream download it for
you and check it out to a local directory, which would have the same
benefits.

Makes sense ?

Cheers,
    -Tristan