<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> </head> <body> <div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">Thiago Macieira <thiago@kde.org>, wrote:<br /></div> <div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br /> <blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">On Friday, 27 October 2017 07:45:38 PDT Laurence Urhegyi wrote:<br /> <blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">So i wanted to kick off this mailing list by trying to round up a few<br /> things which have been discussed recently, at GUADEC, in f2f<br /> conversations afterwards, or shot over emails between a few people. It's<br /> been discussed for a while that we want to create a tiny base runtime<br /> with bst. The upshot is this will homogenize the metadata used in the<br /> build process for Flatpak, GNOME Continuous and eventually many other<br /> projects too, we hope.<br /></blockquote> <br /> Can you give some background on what the problem is in the first place? What is<br /> a tiny base runtime? What is bst? Why was it chosen? Your text talks about<br /> replacing Yocto (a well-known, well-established project with 10 years of<br /> history) with bst, so you need to justify. Or I misunderstood you. <br /></blockquote> <br /> <div><br /></div> <div> My memory of the justification was the result of raising the idea of using BuildStream (1) to build Flatpaks (2) for FlatHub (3) in a session at the GUADEC 2017 Unconference (4). As consensus was approached to consider BuildStream for this application, two possible migration blockers were raised, being A) whether BuildStream had been ported to run on a Yocto runtime, and B) whether the current maintainer of the Yocto runtime being used for FlatHub Flatpaks wanted to keep maintaining the Yocto runtime, or update it to include BuildStream dependencies.</div> <div><br /></div> <div> For A), there were no volunteers to do the porting, although some folk talked about some of the work they had done for other projects to bootstrap systems using LFS (5) techniques with BuildStream. Given B), discussion quickly moved to whether using a distribution runtime would be suitable: this was fairly quickly determined to be unsustainable, as FlatHub has an explicit policy of distribution neutrality. At this point, there was a volunteer who offered to construct BuildStream definitions for the base runtime, which offer was generally accepted.</div> <div><br /></div> <div> My understanding is that this project is not intended to replace Yocto for general application, as Yocto has extensive support tooling to help with many use cases that neither BuildStream nor any bootstrap with BuildStream definitions would cover, but only in the specific cases of building a base for FlatHub Flatpaks and support for GNOME continuous (which has been unable to publish an image for some months, for various reasons, not least a lack of folk actively involved). While both of these are primarily GNOME-facing uses, I imagine that a low-disk-space low-memory base runtime may also be useful for automated testing and validation of other desktop environments or construction of small chroots for various automation support applications, and so support the idea of hosting with Freedesktop, rather than with GNOME or somewhere else. I also understand there was a plan to have a companion project within GNOME, that would handle BuildStream definitions for GNOME-specific common dependencies, to ensure that the mooted Freedesktop project would remain desktop neutral, although I’ve heard nothing about this since GUADEC, so it may remain theoretical, or be dependent on this project.</div> <div><br /></div> <div> For clarity, my memory of the discussions at GUADEC include no clear strategy for wholesale replacement of Yocto, but niche replacement for certain use cases, and in a way that may be useful for similar niche use cases, where a rolling-release model and focus on minimal tooling to build desktop applications is the primary focus, rather than end-user polish, robust platform support, rich developer tooling, or similar.</div> <div><br /></div> <blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">If there have been previous discussions on this subject on other mailing<br /> lists, can you point them out? <br /></blockquote> <div><br /></div> <div> I have not seen any. I remember the discussion at GUADEC, and have seen some IRC chatter since then, but these are the first real posts I’ve seen on the topic.</div> <div><br /></div> <div>1: <a href="https://buildstream.gitlab.io/buildstream/">https://buildstream.gitlab.io/buildstream/</a></div> <div>2: <a href="http://flatpak.org/">http://flatpak.org/</a></div> <div>3: <a href="https://flathub.org/">https://flathub.org/</a></div> <div>4: <a href="https://wiki.gnome.org/GUADEC/2017/Unconference/FlatpakBOF">https://wiki.gnome.org/GUADEC/2017/Unconference/FlatpakBOF</a></div> <div>5: <a href="http://www.linuxfromscratch.org/">http://www.linuxfromscratch.org/</a></div> <div><br /></div> <div>— </div> <div>Emmet HIKORY</div> <div></div> </div> </body> </html>