Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Phil Blundell <pb@pbcl.net>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Gstreamer packaging
Date: Wed, 29 Jun 2011 12:04:42 +0100	[thread overview]
Message-ID: <1309345482.2551.10.camel@phil-desktop> (raw)
In-Reply-To: <1309344835.20015.355.camel@rex>

On Wed, 2011-06-29 at 11:53 +0100, Richard Purdie wrote:
> Obviously you can make the recipe depend on good+bad+ugly but its less
> than ideal for build time reasons (esp. when considering dependencies)
> but also the reason that good/bad/ugly exist in the first place which is
> licensing. 

It's only -ugly which has licensing issues, and those same licensing
issues also mean that plugins don't tend to migrate to or from -ugly in
the same way as they do between the other packages.  So, if -good, -bad
and -base were combined in a single recipe, leaving -ugly separate, that
would solve about 90% of the current nuisance.

Dependency-wise, gst-plugins-good is the only one with a large stack of
DEPENDS.  If you assume that most people are probably going to need at
least one plugin from that package anyway, which I think is probably the
case in reality, then the dependency impact of combining -good, -bad and
-base in a single recipe would be fairly negligible.  (The only extra
dependencies you'd get from -bad would be libmusicbrainz, tremor and
librsvg.)

Of course, another way to attack the dependency stack problem would be
to combine the recipes and then be more aggressive about allowing
DISTROs to select only the plugins (and hence the dependencies) that
they want.  For example, I have long found it slightly annoying that
gst-plugins-good requires gtk+ and x11 at build time since I don't
actually use either of those libraries in my deployed system.

p.





  reply	other threads:[~2011-06-29 11:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-29  9:33 Gstreamer packaging Koen Kooi
2011-06-29  9:55 ` Phil Blundell
2011-06-29 10:53   ` Richard Purdie
2011-06-29 11:04     ` Phil Blundell [this message]
2011-06-29 11:08     ` Phil Blundell
2011-06-29 13:58       ` Richard Purdie

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=1309345482.2551.10.camel@phil-desktop \
    --to=pb@pbcl.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox