All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [RFC] Common code/framework for automatic runtime dependencies
Date: Tue, 17 Sep 2013 21:03:19 -0500	[thread overview]
Message-ID: <523909E7.8020603@windriver.com> (raw)
In-Reply-To: <CABcZANkGd7riMtRE2KfAz+WufoMjr=GYxXHsO2tFSaxXXxS7BQ@mail.gmail.com>

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
>



      reply	other threads:[~2013-09-18  2:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-17 23:23 [RFC] Common code/framework for automatic runtime dependencies Chris Larson
2013-09-18  2:03 ` Mark Hatle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=523909E7.8020603@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.