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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list