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
variations.
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?
References:
1. https://lists.debian.org/debian-embedded/2016/01/msg00003.html
With kind regards,
Baurzhan.
+49 (89) 122 67 24-0
