[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian-based product build system

On Wed, Mar 30, 2016 at 09:17:49PM +0100, Wookey wrote:
> And there is ELBE:
> https://lists.debian.org/debian-embedded/2016/01/msg00000.html
> There does seem to be interest in collaborating here. I hope you can
> find some common ground.

Yes, I've actually mentioned ELBE and this link in the original announcement.

Our colleagues have looked seriously at ELBE. As already mentioned, it produces
the right result and has many features, which is important for us. That said, I
see a number of issues with its current implementation. I don't know it well,
so please correct me if anything is wrong.

* Structure, scalability and variability: ELBE follows a "one image - one
  config file" policy. It's effectively a central tool with a single metadata
  file. This precludes effective component sharing, product and vendor

  There is a proposal to use some XML include mechanism. Splitting an existing
  XML file top-down into three files for two products (one common and two
  product-specific parts) solves the problem only to a small extent, for one
  particular use case. Besides, split commits are very unreadable, especially
  if they contain some adaptations to keep the splitted version functional.
  Including specific files instead of depending on provided features makes
  multiple vendor layering impossible.

  Isar follows Yocto's bottom-up approach, every package having its own recipe.
  In this way, any kind of mix can be defined through dependencies. Recipe
  groups ("layers") can be organized e.g. by vendor, product. This facilitates
  effective component sharing and variability.

* Application development: If I have a product-specific app in an external
  repo, can I dpkg-buildpackage it with ELBE, or do I have to build it myself
  and commit the binary package into an apt repo, to be used later by ELBE?

* Flexibility and extensibility: The elbe tool and the XML file format
  prescribe what one can do with the build system. Implementing anything not
  foreseen by the policy requires either updating the tool (which blocks
  development), or creating wrappers around the tool (which I don't want if I
  have a central tool like elbe).

  Isar performs every step (build a package, create a rootfs) in a separate
  recipe. To add new functionality, a new recipe can be created. The execution
  order is defined by recipe dependencies. Alternatively, an existing recipe
  can be extended, without actually modifying it. This is important if one
  extends an upstream recipe. Upgrading to a newer upstream version doesn't
  result in a tree with conflicts that have to be fixed first.

* Maintainability: The XML file format with blobs isn't very readable (lower
  SNR compared to e.g. BitBake recipes). Neither are patches to it.

  There is an idea of adding a higher-level language translating to XML. That
  would add complexity and make debugging more difficult, so I'm not a fan of
  this approach.

  Isar is a set of individual recipes. Recipes are very terse (for Debian
  packages, almost one-liners without code) and readable (only variable
  assignments and shell / Python code if required). The best way to maintain
  package sources is a repo outside of the project one (compared to committing
  tarballs into the project repo). In this way, blobs are avoided and patches
  are clean.

We would be glad to see if we could find some common ground for collaboration.
Manuel, what do you think?


1. https://lists.debian.org/debian-embedded/2016/01/msg00003.html

With kind regards,
+49 (89) 122 67 24-0

Reply to: