Re: Emdebian
As I read this discussion (all very good stuff, too), I can't help but
want to inject for consideration, an even broader look towards how
Emdebian may be used (or at least, my views on where a major user group
lies), in case it colors decisions being made about how the tools and
practices are developed. I will admit up front that I am not an expert
in Debian policy/procedures, so some of what I discuss may miss the mark
completely for what is or isn't important to Emdebian, but I'd like to
see what the group thinks of my points below. These are really from the
viewpoint of a developer working on an embedded system.
Specifically, I think embedded Linux systems are unlike classic Linux
systems in a few important ways. They are used as the foundation for
many embedded products, where one of the prerequisites in the
development process is the ability to tightly monitor and control
changes to the OS, usually involving some form of source control for
both the sources and the toolchain that are used to build the specific
embedded product. This is necessary, so that a product based on the OS
will have high stability and have been rigorously tested before being
deployed.
Often following initial development, changes to these systems follow a
very conservative approach where it is desirable to be selective in
pulling in updates and changing fundamental system tools such as
toolchains. As such, there is a great desire to be flexible and current
in source and tools during initial development (like a classic Linux
model leveraging package management tools), but once an embedded product
is "baked", there is real value add to gaining finer control over how
one brings new source and new tools (toochains) into the mix. I could
go on and further explore this line of thought, but this is enough for
me to make some generalized points relative to the current discussion
(sorry no specific proposals on tools or policies yet - just food for
thought).
I think many Emdebian consumers will be developers themselves, wanting
to gain some control over their base Linux infrastructure on an embedded
device. As such they will want to be able to do the following things
with the Emdebian packages and toolchains.
1. Be able to easily put a set of Emdebian source packages specific to a
given release of their embedded system under local source control.
2. Be able to leverage package management tools to intelligently bring
in a minimal set of sources and libraries to move forward to get new
features or bugfixes (this is in the stage following the fluid initial
development stage, when the embedded system is in it's conservative
update mode).
3. Have those pieces of the host environment that pertain to managing
and building a set of packages be self contained and well known enough
to be themselves placed under local source control.
4. Be able to construct a toolchain that is largely independent of the
package sources, since changing toolchains following initial development
is far more risky than bringing in new sources.
5. Ideally have source packages that are easy to "lift out" of a Debian
environment wholly self contained so they can be compiled elsewhere.
Often embedded development of complex systems end up using centralized
building environments where many pieces beyond the base OS are brought
together. These centralized build environments arise so that builds can
be automated and serve many developers in a homogeneous manner (one
centralized toolset). Many times these systems may not be a Debian
environment (bureacracy...). The ability to easily integrate the
building of source packages into such an environment would be nice.
There may be an easy way to achieve point 1 already. I am looking at
how I might setup my own source repository (under source control) where
I can store Emdebian packages that I pull from the main Debian mirrors.
Perhaps the tools being discussed can help with this (or at least not
make it harder).
Point 2 is one that I personally find to be of most interest. I really
want to be able to leverage the Debian packaging tools and apt's
dependency management to upgrade pieces of my target root filesystem,
but do so by bringing in the necessary sources for libraries and
dependent packages in a minimally inclusive source set that can then be
built and the sources put under source control. I wonder how the tools
might help me in this regard. What confuses me is that there are really
two kinds of dependencies. Build dependencies and installation
dependencies, and I'm not sure how the two can be used to the effect I
am describing. Ultimately both need to be managed. I haven't heard
anyone propose the cross equivalent functionality of 'apt-get build-dep
<package>'.
Point 3 is a tricky one, but central and also one I find to be of
interest. In a "normal" linux system, the system is its own source
control if you are building Debian packages for local installtion. For
cross development, this is inherently not the case, as we all realize,
and an overriding concern is being able to reproduce build results in
the future. To this end, the pieces integral to reproducibly building
target packages need to be as seperable as possible from the host Debian
installation (i.e. no weird or unknown dependencies on the host Debian
environment). Why this is important, is so that if Emdebian is part of
a larger build environment that serves the purpose of building the OS,
it is at least a reliably reproducible part, and those pieces critical
to reproducibility can be properly source controlled and managed.
Point 4 is a fact of life. It is never ever easy to change a toolchain
once the product ships. New toolchains need to be requalified against
all of the software, and thoroughly regression tested. The emchain
tool, which is designed to stay right up to date with the compiler makes
the most sense from an overall rolling Emdebian point of view, where the
easiest to make sure new packages can be built without much worry. From
the point of view of an embedded developer working on a shipping
product, it would not be an option. Luckily, I don't think this is a
problem, since it doesn't sound tied into the package management side of
things, and is an easy way to get an instantly usable toolchain. I'm
just bringing this up, since in practice, the embedded developer will
most likely need a fixed toolchain that gets updated once in a blue moon.
Point 5 is a minor one and most likely outside the scope of Emdebian,
but still an issue that many developers will struggle with on embedded
projects (I know I am :-).
Thanks for reading,
-Jim Heck
Reply to: