All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: Gstreamer packaging
Date: Wed, 29 Jun 2011 14:58:32 +0100	[thread overview]
Message-ID: <1309355912.20015.388.camel@rex> (raw)
In-Reply-To: <1309345686.2551.13.camel@phil-desktop>

On Wed, 2011-06-29 at 12:08 +0100, Phil Blundell wrote:
> 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. If the recipe always has to depend on good+bad+ugly, it
> > becomes rather tricky to disable ugly and work out whether the resulting
> > configuration can build. Companies interested in license compliance do
> > have a strong need to be able to do this.
> 
> Incidentally, there isn't actually (as far as I can tell) anything in
> the current -ugly recipe which would indicate to an ENTERPRISE_DISTRO
> that this recipe is potentially problematic.  Its LICENSE field just
> reads "GPLv2+ & LGPLv2.1+ & LGPLv2+", which might or might not be
> accurate, and it doesn't appear to have the self-skipping behaviour
> which the corresponding recipe in oe.dev does.

See conf/distro/include/default-distrovars.inc:

# This is a list of packages that require a commercial license to ship
# product. If shipped as part of an image these packages may have 
# implications so they are disabled by default
COMMERCIAL_LICENSE ?= "lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp"
COMMERCIAL_AUDIO_PLUGINS ?= ""
# COMMERCIAL_AUDIO_PLUGINS ?= "gst-plugins-ugly-mad gst-plugins-ugly-mpegaudioparse"
COMMERCIAL_VIDEO_PLUGINS ?= ""
# COMMERCIAL_VIDEO_PLUGINS ?= "gst-plugins-ugly-mpeg2dec gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
COMMERCIAL_QT ?= ""
# COMMERCIAL_QT ?= "qmmp"

I agree we should like have this kind of information indicated at the
recipe level though.

Cheers,

Richard




      reply	other threads:[~2011-06-29 14:17 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
2011-06-29 11:08     ` Phil Blundell
2011-06-29 13:58       ` Richard Purdie [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=1309355912.20015.388.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --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.