[oe] openembedded / dpkg-buildpackage hybrid

[Chris Larson]

On Tue, Nov 23, 2010 at 8:19 AM, Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> there's a debian embedded sprint on in february:
> http://wiki.debian.org/Sprints/2011/EmdebianSprint
>
> i came up with the
> mad idea of modifying openembedded so that it understands debian
> archives, debian/control and rules files, and back-ends into
> dpkg-buildpackage and/or dpkg-cross-buildpackage in order to
> recursively build entire debian archives.
>
> so i wanted to ask people here what they think.
>
> in particular, one of the challenges is that bitbake doesn't cope with
> numbered version dependencies, which i know has been discussed before
> (avoiding regex's) - i wanted to run the idea past people here: how
> about doing the same dependency numbering format as debian control
> files?  "Depends:" can be "python (>= 2.5) " for example or "glibc (>=
> 0.0.1, <= 1.1.3)" which is a simple enough syntax to not be too
> resource-hungry.
>
> and it would solve the rather awkward situation where you have to
> specify blacklists of absolutely every single other version, but then
> someone adds a new bb recipe for that library and of course breaks
> _your_ build as a result, it's all rather fragile.

There are multiple issues with version specific dependencies.  The
syntax is straightforward, I don't see that being a problem.  The work
would be in teaching bitbake's runqueue to obey it.  The other issue
that immediately comes to mind is handling conflicting version
requirements.  Right now the OE sysroot (where files are shared
between dependencies) is global, rather than per-recipe, and if
multiple versions of something get yanked into a build, they'll step
all over one another in that sysroot.  We've discussed possibly moving
to per-recipe sysroots in the past, constructing them on demand based
upon what that recipe requires, but we're not there yet, so I think
we'd have to, for now, just make bitbake freak out and die if the deps
want multiple versions.

I don't see any major problems preventing what you want, at least when
it comes to the version specific dependencies, it's just a matter of
doing the coding to implement it.  Patches welcome ;)



-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics