| Submitter | Koen Kooi |
|---|---|
| Date | Sept. 16, 2011, 8:20 a.m. |
| Message ID | <1316161201-769-1-git-send-email-koen@dominion.thruhere.net> |
| Download | mbox | patch |
| Permalink | /patch/11553/ |
| State | New, archived |
| Headers | show |
Comments
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'
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
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
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.
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
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
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
Patch
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'
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(-)