* Gst-plugin dependencies @ 2011-03-04 15:58 Koen Kooi 2011-03-04 16:46 ` Khem Raj 0 siblings, 1 reply; 8+ messages in thread From: Koen Kooi @ 2011-03-04 15:58 UTC (permalink / raw) To: Patches and discussions about the oe-core layer Hi, The current gst-plguin-<foo> in oe-core is a bit anemic and the ones in OE are really full featured. How do we want to handle this going forward? I'm a big fan of shifting the pain to buildtime so people can install any plugin they want at runtime instead of needing to rebuild it. At TI we have cut-down versions of the recipes to save buildtime[1], but it's a pain to maintain those and keep them up to date. It would be nice to come with a way to say you want full featured gstreamer or not. With my angstrom hat on, I would like the full feature set :) regards, Koen [1] As well as dealing with the inabiltiy to build opencv with a specific CSL toolchain ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Gst-plugin dependencies 2011-03-04 15:58 Gst-plugin dependencies Koen Kooi @ 2011-03-04 16:46 ` Khem Raj 2011-03-04 16:54 ` Mark Hatle 0 siblings, 1 reply; 8+ messages in thread From: Khem Raj @ 2011-03-04 16:46 UTC (permalink / raw) To: openembedded-core On 3/4/2011 7:58 AM, Koen Kooi wrote: > Hi, > > The current gst-plguin-<foo> in oe-core is a bit anemic and the ones in OE are really full featured. How do we want to handle this going forward? I'm a big fan of shifting the pain to buildtime so people can install any plugin they want at runtime instead of needing to rebuild it. > At TI we have cut-down versions of the recipes to save buildtime[1], but it's a pain to maintain those and keep them up to date. It would be nice to come with a way to say you want full featured gstreamer or not. With my angstrom hat on, I would like the full feature set :) > May be controlling it with distro features > regards, > > Koen > > [1] As well as dealing with the inabiltiy to build opencv with a specific CSL toolchain > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Gst-plugin dependencies 2011-03-04 16:46 ` Khem Raj @ 2011-03-04 16:54 ` Mark Hatle 2011-03-04 17:12 ` Koen Kooi 0 siblings, 1 reply; 8+ messages in thread From: Mark Hatle @ 2011-03-04 16:54 UTC (permalink / raw) To: openembedded-core On 3/4/11 10:46 AM, Khem Raj wrote: > On 3/4/2011 7:58 AM, Koen Kooi wrote: >> Hi, >> >> The current gst-plguin-<foo> in oe-core is a bit anemic and the ones in OE are really full featured. How do we want to handle this going forward? I'm a big fan of shifting the pain to buildtime so people can install any plugin they want at runtime instead of needing to rebuild it. >> At TI we have cut-down versions of the recipes to save buildtime[1], but it's a pain to maintain those and keep them up to date. It would be nice to come with a way to say you want full featured gstreamer or not. With my angstrom hat on, I would like the full feature set :) >> > > May be controlling it with distro features Due to the licensing issues in the gst-plugins.. I'd be inclined to say they're out of the core myself. Move it to the distro specific layers. --Mark >> regards, >> >> Koen >> >> [1] As well as dealing with the inabiltiy to build opencv with a specific CSL toolchain >> _______________________________________________ >> Openembedded-core mailing list >> Openembedded-core@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Gst-plugin dependencies 2011-03-04 16:54 ` Mark Hatle @ 2011-03-04 17:12 ` Koen Kooi 2011-03-04 18:50 ` Tom Rini 0 siblings, 1 reply; 8+ messages in thread From: Koen Kooi @ 2011-03-04 17:12 UTC (permalink / raw) To: Patches and discussions about the oe-core layer Op 4 mrt 2011, om 17:54 heeft Mark Hatle het volgende geschreven: > On 3/4/11 10:46 AM, Khem Raj wrote: >> On 3/4/2011 7:58 AM, Koen Kooi wrote: >>> Hi, >>> >>> The current gst-plguin-<foo> in oe-core is a bit anemic and the ones in OE are really full featured. How do we want to handle this going forward? I'm a big fan of shifting the pain to buildtime so people can install any plugin they want at runtime instead of needing to rebuild it. >>> At TI we have cut-down versions of the recipes to save buildtime[1], but it's a pain to maintain those and keep them up to date. It would be nice to come with a way to say you want full featured gstreamer or not. With my angstrom hat on, I would like the full feature set :) >>> >> >> May be controlling it with distro features > > Due to the licensing issues in the gst-plugins.. I'd be inclined to say they're > out of the core myself. Move it to the distro specific layers. Even outside of licensing issues with things like MP3, I would like to have some kind of framework in OE (-core) for gst-plugins that layers can extend to their liking. Having dealt with the recipes over the years, too many things change between versions. It takes someone familiar with gst to maintain those recipes, and there aren't a lot of such people in OE :( regards, Koen ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Gst-plugin dependencies 2011-03-04 17:12 ` Koen Kooi @ 2011-03-04 18:50 ` Tom Rini 2011-03-04 19:01 ` Mark Hatle 0 siblings, 1 reply; 8+ messages in thread From: Tom Rini @ 2011-03-04 18:50 UTC (permalink / raw) To: openembedded-core On 03/04/2011 10:12 AM, Koen Kooi wrote: > > Op 4 mrt 2011, om 17:54 heeft Mark Hatle het volgende geschreven: > >> On 3/4/11 10:46 AM, Khem Raj wrote: >>> On 3/4/2011 7:58 AM, Koen Kooi wrote: >>>> Hi, >>>> >>>> The current gst-plguin-<foo> in oe-core is a bit anemic and the ones in OE are really full featured. How do we want to handle this going forward? I'm a big fan of shifting the pain to buildtime so people can install any plugin they want at runtime instead of needing to rebuild it. >>>> At TI we have cut-down versions of the recipes to save buildtime[1], but it's a pain to maintain those and keep them up to date. It would be nice to come with a way to say you want full featured gstreamer or not. With my angstrom hat on, I would like the full feature set :) >>>> >>> >>> May be controlling it with distro features >> >> Due to the licensing issues in the gst-plugins.. I'd be inclined to say they're >> out of the core myself. Move it to the distro specific layers. > > Even outside of licensing issues with things like MP3, I would like to have some kind of framework in OE (-core) for gst-plugins that layers can extend to their liking. Having dealt with the recipes over the years, too many things change between versions. It takes someone familiar with gst to maintain those recipes, and there aren't a lot of such people in OE :( I agree with Koen, gstreamer is pretty core to doing a lot of stuff in real world applications. We just need a way to handle in a good way the use flag type requirements this brings up. Is the TSC ready to talk about USE flags again yet? I think that could help with the Angstrom hat vs TI hat problem Koen describes too, at least in good part. -- Tom Rini Mentor Graphics Corporation ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Gst-plugin dependencies 2011-03-04 18:50 ` Tom Rini @ 2011-03-04 19:01 ` Mark Hatle 2011-03-04 19:07 ` Khem Raj 2011-03-04 19:32 ` Tom Rini 0 siblings, 2 replies; 8+ messages in thread From: Mark Hatle @ 2011-03-04 19:01 UTC (permalink / raw) To: openembedded-core On 3/4/11 12:50 PM, Tom Rini wrote: > On 03/04/2011 10:12 AM, Koen Kooi wrote: >> >> Op 4 mrt 2011, om 17:54 heeft Mark Hatle het volgende geschreven: >> >>> On 3/4/11 10:46 AM, Khem Raj wrote: >>>> On 3/4/2011 7:58 AM, Koen Kooi wrote: >>>>> Hi, >>>>> >>>>> The current gst-plguin-<foo> in oe-core is a bit anemic and the ones in OE are really full featured. How do we want to handle this going forward? I'm a big fan of shifting the pain to buildtime so people can install any plugin they want at runtime instead of needing to rebuild it. >>>>> At TI we have cut-down versions of the recipes to save buildtime[1], but it's a pain to maintain those and keep them up to date. It would be nice to come with a way to say you want full featured gstreamer or not. With my angstrom hat on, I would like the full feature set :) >>>>> >>>> >>>> May be controlling it with distro features >>> >>> Due to the licensing issues in the gst-plugins.. I'd be inclined to say they're >>> out of the core myself. Move it to the distro specific layers. >> >> Even outside of licensing issues with things like MP3, I would like to have some kind of framework in OE (-core) for gst-plugins that layers can extend to their liking. Having dealt with the recipes over the years, too many things change between versions. It takes someone familiar with gst to maintain those recipes, and there aren't a lot of such people in OE :( > > I agree with Koen, gstreamer is pretty core to doing a lot of stuff in > real world applications. We just need a way to handle in a good way the > use flag type requirements this brings up. > > Is the TSC ready to talk about USE flags again yet? I think that could > help with the Angstrom hat vs TI hat problem Koen describes too, at > least in good part. > In some ways I think it's a bit more fundamental then that. I think we need to have a discussion on what's a "distribution" feature, what's a "FEATURE" and whats a "USE_FLAG" or other things.. and define some of these terms. I know I get confused as to the purpose of these various names and what they are used for already -- (I'm not even sure everyone is talking about the same thing when they say these things) Let me suggest some: A "distribution" feature is one that affects an entire distribution and how it's assembled. Something like "LSB", "PAM", or "SeLinux" support is a distribution feature to me. A "feature" is something specific to a package or subsystem within a distribution. It will enable or disable an optional component that is local to that area. (This allows most of the components, not affected by the feature, to be reused.) --Mark ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Gst-plugin dependencies 2011-03-04 19:01 ` Mark Hatle @ 2011-03-04 19:07 ` Khem Raj 2011-03-04 19:32 ` Tom Rini 1 sibling, 0 replies; 8+ messages in thread From: Khem Raj @ 2011-03-04 19:07 UTC (permalink / raw) To: Patches and discussions about the oe-core layer On Fri, Mar 4, 2011 at 11:01 AM, Mark Hatle <mark.hatle@windriver.com> wrote: > On 3/4/11 12:50 PM, Tom Rini wrote: >> On 03/04/2011 10:12 AM, Koen Kooi wrote: >>> >>> Op 4 mrt 2011, om 17:54 heeft Mark Hatle het volgende geschreven: >>> >>>> On 3/4/11 10:46 AM, Khem Raj wrote: >>>>> On 3/4/2011 7:58 AM, Koen Kooi wrote: >>>>>> Hi, >>>>>> >>>>>> The current gst-plguin-<foo> in oe-core is a bit anemic and the ones in OE are really full featured. How do we want to handle this going forward? I'm a big fan of shifting the pain to buildtime so people can install any plugin they want at runtime instead of needing to rebuild it. >>>>>> At TI we have cut-down versions of the recipes to save buildtime[1], but it's a pain to maintain those and keep them up to date. It would be nice to come with a way to say you want full featured gstreamer or not. With my angstrom hat on, I would like the full feature set :) >>>>>> >>>>> >>>>> May be controlling it with distro features >>>> >>>> Due to the licensing issues in the gst-plugins.. I'd be inclined to say they're >>>> out of the core myself. Move it to the distro specific layers. >>> >>> Even outside of licensing issues with things like MP3, I would like to have some kind of framework in OE (-core) for gst-plugins that layers can extend to their liking. Having dealt with the recipes over the years, too many things change between versions. It takes someone familiar with gst to maintain those recipes, and there aren't a lot of such people in OE :( >> >> I agree with Koen, gstreamer is pretty core to doing a lot of stuff in >> real world applications. We just need a way to handle in a good way the >> use flag type requirements this brings up. >> >> Is the TSC ready to talk about USE flags again yet? I think that could >> help with the Angstrom hat vs TI hat problem Koen describes too, at >> least in good part. >> > > In some ways I think it's a bit more fundamental then that. > > I think we need to have a discussion on what's a "distribution" feature, what's > a "FEATURE" and whats a "USE_FLAG" or other things.. and define some of these terms. > > I know I get confused as to the purpose of these various names and what they are > used for already -- (I'm not even sure everyone is talking about the same thing > when they say these things) > > Let me suggest some: > > A "distribution" feature is one that affects an entire distribution and how it's > assembled. Something like "LSB", "PAM", or "SeLinux" support is a distribution > feature to me. > > A "feature" is something specific to a package or subsystem within a > distribution. It will enable or disable an optional component that is local to > that area. (This allows most of the components, not affected by the feature, to > be reused.) > yes I think its right kind of definition to me. > --Mark > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Gst-plugin dependencies 2011-03-04 19:01 ` Mark Hatle 2011-03-04 19:07 ` Khem Raj @ 2011-03-04 19:32 ` Tom Rini 1 sibling, 0 replies; 8+ messages in thread From: Tom Rini @ 2011-03-04 19:32 UTC (permalink / raw) To: openembedded-core On 03/04/2011 12:01 PM, Mark Hatle wrote: > On 3/4/11 12:50 PM, Tom Rini wrote: >> On 03/04/2011 10:12 AM, Koen Kooi wrote: >>> >>> Op 4 mrt 2011, om 17:54 heeft Mark Hatle het volgende geschreven: >>> >>>> On 3/4/11 10:46 AM, Khem Raj wrote: >>>>> On 3/4/2011 7:58 AM, Koen Kooi wrote: >>>>>> Hi, >>>>>> >>>>>> The current gst-plguin-<foo> in oe-core is a bit anemic and the ones in OE are really full featured. How do we want to handle this going forward? I'm a big fan of shifting the pain to buildtime so people can install any plugin they want at runtime instead of needing to rebuild it. >>>>>> At TI we have cut-down versions of the recipes to save buildtime[1], but it's a pain to maintain those and keep them up to date. It would be nice to come with a way to say you want full featured gstreamer or not. With my angstrom hat on, I would like the full feature set :) >>>>>> >>>>> >>>>> May be controlling it with distro features >>>> >>>> Due to the licensing issues in the gst-plugins.. I'd be inclined to say they're >>>> out of the core myself. Move it to the distro specific layers. >>> >>> Even outside of licensing issues with things like MP3, I would like to have some kind of framework in OE (-core) for gst-plugins that layers can extend to their liking. Having dealt with the recipes over the years, too many things change between versions. It takes someone familiar with gst to maintain those recipes, and there aren't a lot of such people in OE :( >> >> I agree with Koen, gstreamer is pretty core to doing a lot of stuff in >> real world applications. We just need a way to handle in a good way the >> use flag type requirements this brings up. >> >> Is the TSC ready to talk about USE flags again yet? I think that could >> help with the Angstrom hat vs TI hat problem Koen describes too, at >> least in good part. >> > > In some ways I think it's a bit more fundamental then that. > > I think we need to have a discussion on what's a "distribution" feature, what's > a "FEATURE" and whats a "USE_FLAG" or other things.. and define some of these terms. > > I know I get confused as to the purpose of these various names and what they are > used for already -- (I'm not even sure everyone is talking about the same thing > when they say these things) > > Let me suggest some: > > A "distribution" feature is one that affects an entire distribution and how it's > assembled. Something like "LSB", "PAM", or "SeLinux" support is a distribution > feature to me. > > A "feature" is something specific to a package or subsystem within a > distribution. It will enable or disable an optional component that is local to > that area. (This allows most of the components, not affected by the feature, to > be reused.) Yes, talking about this will also need to agree on terminology for what should be a distribution feature, a machine feature, a "feature feature" and when they intersect, and what's still outside of that. But I do agree with what you've said so far. -- Tom Rini Mentor Graphics Corporation ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-03-04 19:33 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-04 15:58 Gst-plugin dependencies Koen Kooi 2011-03-04 16:46 ` Khem Raj 2011-03-04 16:54 ` Mark Hatle 2011-03-04 17:12 ` Koen Kooi 2011-03-04 18:50 ` Tom Rini 2011-03-04 19:01 ` Mark Hatle 2011-03-04 19:07 ` Khem Raj 2011-03-04 19:32 ` Tom Rini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox