[RFC 1/2] gstreamer: sync packaging with OE .dev

[RFC 1/2] gstreamer: sync packaging with OE .dev

[Koen Kooi]

some text here

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 .../gstreamer/gst-plugins-package.inc              |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
index 796df14..dae9416 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
@@ -6,8 +6,8 @@ python populate_packages_prepend () {
 	glibdir = bb.data.expand('${libdir}', d)
 
 	do_split_packages(d, glibdir, '^lib(.*)\.so\.*', 'lib%s', 'gstreamer %s library', extra_depends='', allow_links=True)
-	do_split_packages(d, gst_libdir, 'libgst(.*)\.so$', bb.data.expand('${PN}-%s', d), 'GStreamer plugin for %s', postinst=postinst, extra_depends=bb.data.expand('${PN}',d))
-	do_split_packages(d, gst_libdir, 'libgst(.*)\.l?a$', bb.data.expand('${PN}-%s-dev', d), 'GStreamer plugin for %s (development files)', extra_depends=bb.data.expand('${PN}-dev',d))
+	do_split_packages(d, gst_libdir, '^libgst(.*)\.so$', 'gst-plugin-%s', 'GStreamer plugin for %s', postinst=postinst, extra_depends='')
+	do_split_packages(d, gst_libdir, '^libgst(.*)\.l?a$', 'gst-plugin-%s-dev', 'GStreamer plugin for %s (development files)', extra_depends='')
 	
 	pn = bb.data.getVar('PN', d, 1)
 	metapkg =  pn + '-meta'
-- 
1.6.6.1

[RFC 2/2] gst-meta-base: adjust plugin names after gstreamer packaging changes

[Koen Kooi]

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
---
 .../gstreamer/gst-meta-base_0.10.bb                |   50 ++++++++++----------
 1 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb b/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb
index 1788104..ed80ac1 100644
--- a/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-meta-base_0.10.bb
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3
                     file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
 
-PR = "r10"
+PR = "r11"
 
 PACKAGES = "\
     gst-meta-base \
@@ -17,43 +17,43 @@ ALLOW_EMPTY = "1"
 
 RDEPENDS_gst-meta-base = "\
     gstreamer \
-    gst-plugins-base-playbin \
-    gst-plugins-base-decodebin \
-    gst-plugins-base-decodebin2 \
-    gst-plugins-base-gio \
-    gst-plugins-base-alsa \
-    gst-plugins-base-volume \
-    gst-plugins-base-ximagesink \
-    gst-plugins-base-audioconvert \
-    gst-plugins-base-audioresample \
-    gst-plugins-base-typefindfunctions \
-    gst-plugins-base-videoscale \
-    gst-plugins-base-ffmpegcolorspace \
-    gst-plugins-good-autodetect \
-    gst-plugins-good-souphttpsrc"
+    gst-plugin-playbin \
+    gst-plugin-decodebin \
+    gst-plugin-decodebin2 \
+    gst-plugin-gio \
+    gst-plugin-alsa \
+    gst-plugin-volume \
+    gst-plugin-ximagesink \
+    gst-plugin-audioconvert \
+    gst-plugin-audioresample \
+    gst-plugin-typefindfunctions \
+    gst-plugin-videoscale \
+    gst-plugin-ffmpegcolorspace \
+    gst-plugin-autodetect \
+    gst-plugin-souphttpsrc"
 
 
 RDEPENDS_gst-meta-audio = "\
     gst-meta-base \
-    gst-plugins-base-vorbis \
-    gst-plugins-base-ogg \
-    gst-plugins-good-wavparse \
-    gst-plugins-good-flac \
+    gst-plugin-vorbis \
+    gst-plugin-ogg \
+    gst-plugin-wavparse \
+    gst-plugin-flac \
     ${COMMERCIAL_AUDIO_PLUGINS}"
 
 
 RDEPENDS_gst-meta-debug = "\
     gst-meta-base \
-    gst-plugins-good-debug \
-    gst-plugins-base-audiotestsrc \
-    gst-plugins-base-videotestsrc"
+    gst-plugin-debug \
+    gst-plugin-audiotestsrc \
+    gst-plugin-videotestsrc"
 
 
 RDEPENDS_gst-meta-video = "\
     gst-meta-base \
-    gst-plugins-good-avi \
-    gst-plugins-good-matroska \
-    gst-plugins-base-theora \
+    gst-plugin-avi \
+    gst-plugin-matroska \
+    gst-plugin-theora \
     ${COMMERCIAL_VIDEO_PLUGINS}"
 
 RRECOMMENDS_gst-meta-video = "\
-- 
1.6.6.1

Re: [RFC 1/2] gstreamer: sync packaging with OE .dev

[Richard Purdie]

On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote:
> some text here

It took all my restraint to not just reply with:
"""
NAK

<insert reason for NAK here, I can't be bothered to type it>
"""

We've been around in a few circles with this. The problem is that if we
apply this patch we have no clue which gst-plugin from the good, the bad
and the ugly provides something you're after to include in an image.
This results in bitbake being pretty clueless about whether a given
build will succeed or not. In general I'm not a fan of having
non-deterministic builds as they tend to annoy users.

If this position isn't acceptable then we'll probably have to move to a
situation where we list which plugins each of the packages builds and
drop the dyanmic provides. That is a maintenance pain and I don't take
that step lightly but I don't see any other options. I'm open to
suggestions though.

Cheers,

Richard

> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
>  .../gstreamer/gst-plugins-package.inc              |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
> index 796df14..dae9416 100644
> --- a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
> +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
> @@ -6,8 +6,8 @@ python populate_packages_prepend () {
>  	glibdir = bb.data.expand('${libdir}', d)
>  
>  	do_split_packages(d, glibdir, '^lib(.*)\.so\.*', 'lib%s', 'gstreamer %s library', extra_depends='', allow_links=True)
> -	do_split_packages(d, gst_libdir, 'libgst(.*)\.so$', bb.data.expand('${PN}-%s', d), 'GStreamer plugin for %s', postinst=postinst, extra_depends=bb.data.expand('${PN}',d))
> -	do_split_packages(d, gst_libdir, 'libgst(.*)\.l?a$', bb.data.expand('${PN}-%s-dev', d), 'GStreamer plugin for %s (development files)', extra_depends=bb.data.expand('${PN}-dev',d))
> +	do_split_packages(d, gst_libdir, '^libgst(.*)\.so$', 'gst-plugin-%s', 'GStreamer plugin for %s', postinst=postinst, extra_depends='')
> +	do_split_packages(d, gst_libdir, '^libgst(.*)\.l?a$', 'gst-plugin-%s-dev', 'GStreamer plugin for %s (development files)', extra_depends='')
>  	
>  	pn = bb.data.getVar('PN', d, 1)
>  	metapkg =  pn + '-meta'

Re: [RFC 1/2] gstreamer: sync packaging with OE .dev

[Martin Jansa]

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

On Fri, Sep 16, 2011 at 11:09:49AM +0100, Richard Purdie wrote:
> On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote:
> > some text here
> 
> It took all my restraint to not just reply with:
> """
> NAK
> 
> <insert reason for NAK here, I can't be bothered to type it>
> """
> 
> We've been around in a few circles with this. The problem is that if we
> apply this patch we have no clue which gst-plugin from the good, the bad
> and the ugly provides something you're after to include in an image.
> This results in bitbake being pretty clueless about whether a given
> build will succeed or not. In general I'm not a fan of having
> non-deterministic builds as they tend to annoy users.
> 
> If this position isn't acceptable then we'll probably have to move to a
> situation where we list which plugins each of the packages builds and
> drop the dyanmic provides. That is a maintenance pain and I don't take
> that step lightly but I don't see any other options. I'm open to
> suggestions though.

Something like:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031739.html
http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031740.html
?

Regards,

> 
> Cheers,
> 
> Richard
> 
> > Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> > ---
> >  .../gstreamer/gst-plugins-package.inc              |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
> > index 796df14..dae9416 100644
> > --- a/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
> > +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-package.inc
> > @@ -6,8 +6,8 @@ python populate_packages_prepend () {
> >  	glibdir = bb.data.expand('${libdir}', d)
> >  
> >  	do_split_packages(d, glibdir, '^lib(.*)\.so\.*', 'lib%s', 'gstreamer %s library', extra_depends='', allow_links=True)
> > -	do_split_packages(d, gst_libdir, 'libgst(.*)\.so$', bb.data.expand('${PN}-%s', d), 'GStreamer plugin for %s', postinst=postinst, extra_depends=bb.data.expand('${PN}',d))
> > -	do_split_packages(d, gst_libdir, 'libgst(.*)\.l?a$', bb.data.expand('${PN}-%s-dev', d), 'GStreamer plugin for %s (development files)', extra_depends=bb.data.expand('${PN}-dev',d))
> > +	do_split_packages(d, gst_libdir, '^libgst(.*)\.so$', 'gst-plugin-%s', 'GStreamer plugin for %s', postinst=postinst, extra_depends='')
> > +	do_split_packages(d, gst_libdir, '^libgst(.*)\.l?a$', 'gst-plugin-%s-dev', 'GStreamer plugin for %s (development files)', extra_depends='')
> >  	
> >  	pn = bb.data.getVar('PN', d, 1)
> >  	metapkg =  pn + '-meta'
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [RFC 1/2] gstreamer: sync packaging with OE .dev

[Richard Purdie]

On Fri, 2011-09-16 at 12:19 +0200, Martin Jansa wrote:
> On Fri, Sep 16, 2011 at 11:09:49AM +0100, Richard Purdie wrote:
> > On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote:
> > > some text here
> > 
> > It took all my restraint to not just reply with:
> > """
> > NAK
> > 
> > <insert reason for NAK here, I can't be bothered to type it>
> > """
> > 
> > We've been around in a few circles with this. The problem is that if we
> > apply this patch we have no clue which gst-plugin from the good, the bad
> > and the ugly provides something you're after to include in an image.
> > This results in bitbake being pretty clueless about whether a given
> > build will succeed or not. In general I'm not a fan of having
> > non-deterministic builds as they tend to annoy users.
> > 
> > If this position isn't acceptable then we'll probably have to move to a
> > situation where we list which plugins each of the packages builds and
> > drop the dyanmic provides. That is a maintenance pain and I don't take
> > that step lightly but I don't see any other options. I'm open to
> > suggestions though.
> 
> Something like:
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031739.html
> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031740.html
> ?

Yes. I'd probably have written separate .inc files to simplify the
script but I'm thinking along those lines. I'm not particularly happy
about it but I don't see many other options.

Cheers,

Richard

Re: [RFC 1/2] gstreamer: sync packaging with OE .dev

[Phil Blundell]

On Fri, 2011-09-16 at 12:00 +0100, Richard Purdie wrote:
> On Fri, 2011-09-16 at 12:19 +0200, Martin Jansa wrote:
> > On Fri, Sep 16, 2011 at 11:09:49AM +0100, Richard Purdie wrote:
> > > On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote:
> > > > some text here
> > > 
> > > It took all my restraint to not just reply with:
> > > """
> > > NAK
> > > 
> > > <insert reason for NAK here, I can't be bothered to type it>
> > > """
> > > 
> > > We've been around in a few circles with this. The problem is that if we
> > > apply this patch we have no clue which gst-plugin from the good, the bad
> > > and the ugly provides something you're after to include in an image.
> > > This results in bitbake being pretty clueless about whether a given
> > > build will succeed or not. In general I'm not a fan of having
> > > non-deterministic builds as they tend to annoy users.
> > > 
> > > If this position isn't acceptable then we'll probably have to move to a
> > > situation where we list which plugins each of the packages builds and
> > > drop the dyanmic provides. That is a maintenance pain and I don't take
> > > that step lightly but I don't see any other options. I'm open to
> > > suggestions though.
> > 
> > Something like:
> > http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031739.html
> > http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031740.html
> > ?
> 
> Yes. I'd probably have written separate .inc files to simplify the
> script but I'm thinking along those lines. I'm not particularly happy
> about it but I don't see many other options.

Last time this issue came up we talked about simply merging the -good,
-bad and -base plugins into a single recipe (since there appears to be
no very compelling reason to keep them separate) and just leaving the
-ugly ones on their own.  That still seems to me as though it is the
best way of making a lot of that complexity just go away.  Then
something like Martin's script could be used to figure out the (mostly
static, with a bit of luck) split between -ugly and the rest.

p.

Re: [RFC 1/2] gstreamer: sync packaging with OE .dev

[Richard Purdie]

On Fri, 2011-09-16 at 12:06 +0100, Phil Blundell wrote:
> On Fri, 2011-09-16 at 12:00 +0100, Richard Purdie wrote:
> > On Fri, 2011-09-16 at 12:19 +0200, Martin Jansa wrote:
> > > On Fri, Sep 16, 2011 at 11:09:49AM +0100, Richard Purdie wrote:
> > > > On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote:
> > > > > some text here
> > > > 
> > > > It took all my restraint to not just reply with:
> > > > """
> > > > NAK
> > > > 
> > > > <insert reason for NAK here, I can't be bothered to type it>
> > > > """
> > > > 
> > > > We've been around in a few circles with this. The problem is that if we
> > > > apply this patch we have no clue which gst-plugin from the good, the bad
> > > > and the ugly provides something you're after to include in an image.
> > > > This results in bitbake being pretty clueless about whether a given
> > > > build will succeed or not. In general I'm not a fan of having
> > > > non-deterministic builds as they tend to annoy users.
> > > > 
> > > > If this position isn't acceptable then we'll probably have to move to a
> > > > situation where we list which plugins each of the packages builds and
> > > > drop the dyanmic provides. That is a maintenance pain and I don't take
> > > > that step lightly but I don't see any other options. I'm open to
> > > > suggestions though.
> > > 
> > > Something like:
> > > http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031739.html
> > > http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031740.html
> > > ?
> > 
> > Yes. I'd probably have written separate .inc files to simplify the
> > script but I'm thinking along those lines. I'm not particularly happy
> > about it but I don't see many other options.
> 
> Last time this issue came up we talked about simply merging the -good,
> -bad and -base plugins into a single recipe (since there appears to be
> no very compelling reason to keep them separate) and just leaving the
> -ugly ones on their own.  That still seems to me as though it is the
> best way of making a lot of that complexity just go away.  Then
> something like Martin's script could be used to figure out the (mostly
> static, with a bit of luck) split between -ugly and the rest.

When put like this it doesn't sound so attractive since you need the
scripts for ugly anyway. Keeping them separate does actually help build
time at least since the plugins are one of the last things to get built
and if merged, you also have to merge all the dependencies, compounding
the build time.

Cheers,

Richard

Re: [RFC 1/2] gstreamer: sync packaging with OE .dev

[Koen Kooi]

Op 16 sep 2011, om 15:38 heeft Richard Purdie het volgende geschreven:

> On Fri, 2011-09-16 at 12:06 +0100, Phil Blundell wrote:
>> On Fri, 2011-09-16 at 12:00 +0100, Richard Purdie wrote:
>>> On Fri, 2011-09-16 at 12:19 +0200, Martin Jansa wrote:
>>>> On Fri, Sep 16, 2011 at 11:09:49AM +0100, Richard Purdie wrote:
>>>>> On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote:
>>>>>> some text here
>>>>>
>>>>> It took all my restraint to not just reply with:
>>>>> """
>>>>> NAK
>>>>>
>>>>> <insert reason for NAK here, I can't be bothered to type it>
>>>>> """
>>>>>
>>>>> We've been around in a few circles with this. The problem is  
>>>>> that if we
>>>>> apply this patch we have no clue which gst-plugin from the good,  
>>>>> the bad
>>>>> and the ugly provides something you're after to include in an  
>>>>> image.
>>>>> This results in bitbake being pretty clueless about whether a  
>>>>> given
>>>>> build will succeed or not. In general I'm not a fan of having
>>>>> non-deterministic builds as they tend to annoy users.
>>>>>
>>>>> If this position isn't acceptable then we'll probably have to  
>>>>> move to a
>>>>> situation where we list which plugins each of the packages  
>>>>> builds and
>>>>> drop the dyanmic provides. That is a maintenance pain and I  
>>>>> don't take
>>>>> that step lightly but I don't see any other options. I'm open to
>>>>> suggestions though.
>>>>
>>>> Something like:
>>>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031739.html
>>>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031740.html
>>>> ?
>>>
>>> Yes. I'd probably have written separate .inc files to simplify the
>>> script but I'm thinking along those lines. I'm not particularly  
>>> happy
>>> about it but I don't see many other options.
>>
>> Last time this issue came up we talked about simply merging the - 
>> good,
>> -bad and -base plugins into a single recipe (since there appears to  
>> be
>> no very compelling reason to keep them separate) and just leaving the
>> -ugly ones on their own.  That still seems to me as though it is the
>> best way of making a lot of that complexity just go away.  Then
>> something like Martin's script could be used to figure out the  
>> (mostly
>> static, with a bit of luck) split between -ugly and the rest.
>
> When put like this it doesn't sound so attractive since you need the
> scripts for ugly anyway. Keeping them separate does actually help  
> build
> time at least since the plugins are one of the last things to get  
> built
> and if merged, you also have to merge all the dependencies,  
> compounding
> the build time.

If someone can tell me which solution is preferred I can start working  
on patches :)

regards,

Koen

Re: [RFC 1/2] gstreamer: sync packaging with OE .dev

[Richard Purdie]

On Thu, 2011-09-22 at 13:32 +0200, Koen Kooi wrote:
> Op 16 sep 2011, om 15:38 heeft Richard Purdie het volgende geschreven:
> 
> > On Fri, 2011-09-16 at 12:06 +0100, Phil Blundell wrote:
> >> On Fri, 2011-09-16 at 12:00 +0100, Richard Purdie wrote:
> >>> On Fri, 2011-09-16 at 12:19 +0200, Martin Jansa wrote:
> >>>> On Fri, Sep 16, 2011 at 11:09:49AM +0100, Richard Purdie wrote:
> >>>>> On Fri, 2011-09-16 at 10:20 +0200, Koen Kooi wrote:
> >>>>>> some text here
> >>>>>
> >>>>> It took all my restraint to not just reply with:
> >>>>> """
> >>>>> NAK
> >>>>>
> >>>>> <insert reason for NAK here, I can't be bothered to type it>
> >>>>> """
> >>>>>
> >>>>> We've been around in a few circles with this. The problem is  
> >>>>> that if we
> >>>>> apply this patch we have no clue which gst-plugin from the good,  
> >>>>> the bad
> >>>>> and the ugly provides something you're after to include in an  
> >>>>> image.
> >>>>> This results in bitbake being pretty clueless about whether a  
> >>>>> given
> >>>>> build will succeed or not. In general I'm not a fan of having
> >>>>> non-deterministic builds as they tend to annoy users.
> >>>>>
> >>>>> If this position isn't acceptable then we'll probably have to  
> >>>>> move to a
> >>>>> situation where we list which plugins each of the packages  
> >>>>> builds and
> >>>>> drop the dyanmic provides. That is a maintenance pain and I  
> >>>>> don't take
> >>>>> that step lightly but I don't see any other options. I'm open to
> >>>>> suggestions though.
> >>>>
> >>>> Something like:
> >>>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031739.html
> >>>> http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-April/031740.html
> >>>> ?
> >>>
> >>> Yes. I'd probably have written separate .inc files to simplify the
> >>> script but I'm thinking along those lines. I'm not particularly  
> >>> happy
> >>> about it but I don't see many other options.
> >>
> >> Last time this issue came up we talked about simply merging the - 
> >> good,
> >> -bad and -base plugins into a single recipe (since there appears to  
> >> be
> >> no very compelling reason to keep them separate) and just leaving the
> >> -ugly ones on their own.  That still seems to me as though it is the
> >> best way of making a lot of that complexity just go away.  Then
> >> something like Martin's script could be used to figure out the  
> >> (mostly
> >> static, with a bit of luck) split between -ugly and the rest.
> >
> > When put like this it doesn't sound so attractive since you need the
> > scripts for ugly anyway. Keeping them separate does actually help  
> > build
> > time at least since the plugins are one of the last things to get  
> > built
> > and if merged, you also have to merge all the dependencies,  
> > compounding
> > the build time.
> 
> If someone can tell me which solution is preferred I can start working  
> on patches :)

I'm preferring the script generating the list of provides for the
gstreamer recipe...

Cheers,

Richard