[RFC] Common code/framework for automatic runtime dependencies

[RFC] Common code/framework for automatic runtime dependencies

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

Greetings,

I recently found myself wanting to implement a prototype of automatic
python dependencies. In so doing, I realized that there's a certain pattern
followed by each of these (shlibs, pkgconfig, kernel modules, ..), so I'd
like to propose, in the 1.6 timeframe, consolidating this into common core
code to make it easier to implement additional types of automatic rdepends
where appopriate. This would also make it easy to enable a sanity check
across all types to warn/fail if an automatic rdepend was generated for a
recipe which isn't also explicitly included in the depends, to catch
non-deterministic build issues.

Does this concept seem relatively sane? I have a prototype of this in a
layer that I've been playing with. I have so far added two modules for it,
a pkg-config one that I've confirmed is behaving the same as the existing
pkg-config dep handling, and a prototype python one which works for the
most part, but is still a work-in-progress. I'd appreciate any comments on
this. If folks don't think this is a good approach, I'm open to that too,
but it seemed silly to have these things reimplemented or duplicated when
the logic appears to be the same.

See https://github.com/kergoth/meta-package-auto-deps for the prototype.
https://github.com/kergoth/meta-package-auto-deps/blob/master/TODO.md shows
my next steps.

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

[-- Attachment #2: Type: text/html, Size: 1865 bytes --]

Re: [RFC] Common code/framework for automatic runtime dependencies

[Mark Hatle]

On 9/17/13 6:23 PM, Chris Larson wrote:
> Greetings,
>
> I recently found myself wanting to implement a prototype of automatic python
> dependencies. In so doing, I realized that there's a certain pattern followed by
> each of these (shlibs, pkgconfig, kernel modules, ..), so I'd like to propose,
> in the 1.6 timeframe, consolidating this into common core code to make it easier
> to implement additional types of automatic rdepends where appopriate. This would
> also make it easy to enable a sanity check across all types to warn/fail if an
> automatic rdepend was generated for a recipe which isn't also explicitly
> included in the depends, to catch non-deterministic build issues.

The rpmdeps that is run, as part of the RPM packaging, has a series of these 
types of checks already.

We really should try to come up with a single instance of dependency 
information, be it SONAME, #!, etc..  For things that can't be represented in 
some package types (like specific filenames), a way to set the rules and filter 
those would be needed.

> Does this concept seem relatively sane? I have a prototype of this in a layer
> that I've been playing with. I have so far added two modules for it, a
> pkg-config one that I've confirmed is behaving the same as the existing
> pkg-config dep handling, and a prototype python one which works for the most
> part, but is still a work-in-progress. I'd appreciate any comments on this. If
> folks don't think this is a good approach, I'm open to that too, but it seemed
> silly to have these things reimplemented or duplicated when the logic appears to
> be the same.

Yes, I think this is needed.  RPM is covering some of this work already, but 
there is much duplicated logic already, and I'd love to get rid of the 
duplication, but retain the additional checks RPM gives the user (when rpm 
packaging is enabled.)

--Mark

> See https://github.com/kergoth/meta-package-auto-deps for the prototype.
> https://github.com/kergoth/meta-package-auto-deps/blob/master/TODO.md shows my
> next steps.
>
> Thanks for your time,
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>