Re: status of meta-eid ?

[ydirson@free.fr]

Hi Henning,

> Am Sun, 24 Oct 2021 21:18:53 +0200 (CEST)
> schrieb ydirson@free.fr:
> 
> > Hi Baurzhan,
> > 
> > > sbuild preview is available in [1].
> > 
> > Nice!
> > 
> > > If you are interested, we could share the current state.
> > 
> > I still have quite a lot in dig in right now, so don't divert
> > efforts
> > :)
> > 
> > My main focus for now is a bit far from this - I still need to get
> > familiar with the current state of things, with in mind the idea of
> > possibly using ISAR as a next-gen build system[1] for QubesOS[0] (a
> > bit of a personal research project to see if it can help to improve
> > the dev workflow there)
> > 
> > [0] https://qubes-os.org/
> > [1]
> > https://forum.qubes-os.org/t/ideas-for-next-generation-qubes-builder/6402
> 
> Cater as a build system for an OSS project like qubes-os would be
> cool.
> I looked into 1 and it seems qubes-os is currently based on fedora.
>
> Making isar work for that would be possible but not an easy task. It
> is
> already hard to keep all the different flavours/versions of debian
> maintained and working. Plus we are building on top of
> qemu-debootstrap
> for native builds of non-host architectures. A very powerful thing
> that
> might be missing some bits in other distros.
> 
> In fact Isar is not a lot of code, and most of it is very much debian
> specific. The easiest way to go might be switching base distros,
> which
> might bring you "back in time" and on a slower release cycle your
> might
> be used to. And if you carry a lot of your own spec-files, those will
> need translation into "debian/" folders.
> 
> Also note that Isars main feature is building complete bootable
> images,
> or OTA-update rootfss. For more than just a rootfs, partitioning and
> bootloader stuff come into play. It also builds debian package repos
> for later offline rebuild or for shipping package-based updates with
> apt.
> If your main concern is building packages, and maybe package repos
> ...
> it might be too big of a gun (but will work). On the other hand full
> bootable image is what you might still need for automated continous
> testing in qemu or on real devices.


QubesOS encompasses quite a number of things, the most prominent ones from my
PoV being:

- the virtualization layer and dom0, which happen to be fedora-based today,
  but will likely not stay that way in the long run, see eg. [0].  This
  one will for a start essentially benefit from better package-building
  capabilities (eg. don't rebuild all dependent packages every time)

- the VM templates, which include as standard Fedora, Debian, and Whonix.
  They are indeed OS images, and it will not be a large amount of work to
  produce those for Debian with ISAR, as all VM tools already come with
  Debian packaging.

- the assembled OS itself, which is out of my scope for now (as I understand it,
  it is mostly a customized installer for the dom0 OS)

This last point excluded, the first 2 ones both need to build some custom
packages and modified versions of upstream ones, so ISAR features still seem
to address a big part of the needs.

My plan (as outline in [1]) is to have a closer look at rootfs and package
building, to get a measure of the amount of work to adapt for a rpm distro.
I guess most of it can live in a separate meta-isar-rpm layer, and a
meta-isar-qubes can be build on top of that.


[0] https://forum.qubes-os.org/t/alpine-linux-in-dom0/7077/4
[1] https://forum.qubes-os.org/t/ideas-for-next-generation-qubes-builder/6402/2