All of lore.kernel.org
 help / color / mirror / Atom feed
* gst-plugins-base -> gnome-vfs question
@ 2009-10-27 13:31 Sebastian Spaeth
  2009-10-27 13:44 ` Koen Kooi
  2009-10-27 13:53 ` Graeme Gregory
  0 siblings, 2 replies; 5+ messages in thread
From: Sebastian Spaeth @ 2009-10-27 13:31 UTC (permalink / raw)
  To: openembedded-devel

Current "gst-plugins-base" in org.oe.dev unconditionally depends on
"gnome-vfs" which in turn pulls in stuff like "avahi".

Is that what most people in OE want? It can be turned off on compile
time with: "--disable-gnome_vfs", making it optional.

I don't want avahi on my Freerunner, just because I want sound on it :-).

Should we look into an OEXTRA_CONF solution? Let me know if I have said
something dumb here or overlooked something obvious.

Thanks,
spaetz



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: gst-plugins-base -> gnome-vfs question
  2009-10-27 13:31 gst-plugins-base -> gnome-vfs question Sebastian Spaeth
@ 2009-10-27 13:44 ` Koen Kooi
  2009-10-27 13:59   ` Sebastian Spaeth
  2009-10-27 13:53 ` Graeme Gregory
  1 sibling, 1 reply; 5+ messages in thread
From: Koen Kooi @ 2009-10-27 13:44 UTC (permalink / raw)
  To: openembedded-devel

On 27-10-09 14:31, Sebastian Spaeth wrote:
> Current "gst-plugins-base" in org.oe.dev unconditionally depends on
> "gnome-vfs" which in turn pulls in stuff like "avahi".
>
> Is that what most people in OE want? It can be turned off on compile
> time with: "--disable-gnome_vfs", making it optional.

It's already optional, don't install gst-plugin-gnomevfs

> I don't want avahi on my Freerunner, just because I want sound on it :-).

I think you are confusing avahi and pulseaudio, in both cases you need 
to read up on the subject.

> Should we look into an OEXTRA_CONF solution? Let me know if I have said
> something dumb here or overlooked something obvious.

You overlooked that installing gst-plugin-gnomevfs is completely your 
own choice




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: gst-plugins-base -> gnome-vfs question
  2009-10-27 13:31 gst-plugins-base -> gnome-vfs question Sebastian Spaeth
  2009-10-27 13:44 ` Koen Kooi
@ 2009-10-27 13:53 ` Graeme Gregory
  1 sibling, 0 replies; 5+ messages in thread
From: Graeme Gregory @ 2009-10-27 13:53 UTC (permalink / raw)
  To: openembedded-devel

On Tue, Oct 27, 2009 at 02:31:01PM +0100, Sebastian Spaeth wrote:
> I don't want avahi on my Freerunner, just because I want sound on it :-).
> 
Eh and what????

Since I wrote the sound drivers for Freerunner Ive never had avahi
disable them.

avahi is one of the best networking tools ever written, I cant think
of any reason someone wouldnt want it on Freerunner.

XorA




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: gst-plugins-base -> gnome-vfs question
  2009-10-27 13:44 ` Koen Kooi
@ 2009-10-27 13:59   ` Sebastian Spaeth
  2009-10-27 14:24     ` Koen Kooi
  0 siblings, 1 reply; 5+ messages in thread
From: Sebastian Spaeth @ 2009-10-27 13:59 UTC (permalink / raw)
  To: openembedded-devel

Koen Kooi wrote:
> On 27-10-09 14:31, Sebastian Spaeth wrote:
>> Current "gst-plugins-base" in org.oe.dev unconditionally depends on
>> "gnome-vfs" which in turn pulls in stuff like "avahi".

> It's already optional, don't install gst-plugin-gnomevfs
Thanks for the quick reply.
I was referring to the fact that the "gst-plugins-base" package directly
depends on gnome-vfs.

eg.
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/gstreamer/gst-plugins-base_0.10.22.bb
contains:
DEPENDS += "libtheora alsa-lib libsm virtual/libx11 freetype gnome-vfs
libxv"

This does not look very optional to me. I keep thinking that there must
be something very obvious that I have missed.

>> I don't want avahi on my Freerunner, just because I want sound on it :-).
> I think you are confusing avahi and pulseaudio, in both cases you need
> to read up on the subject.

I do know the difference between avahi and pulseaudio, thank you ;-).

> You overlooked that installing gst-plugin-gnomevfs is completely your
> own choice

but gst-plugins-base pulling in gnome-vfs in its DEPENDS is not
optional, right?

Anyway, thanks for you quick reply. I guess I must have overlooked
something glaringly obvious here...

spaetz



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: gst-plugins-base -> gnome-vfs question
  2009-10-27 13:59   ` Sebastian Spaeth
@ 2009-10-27 14:24     ` Koen Kooi
  0 siblings, 0 replies; 5+ messages in thread
From: Koen Kooi @ 2009-10-27 14:24 UTC (permalink / raw)
  To: openembedded-devel

On 27-10-09 14:59, Sebastian Spaeth wrote:
> Koen Kooi wrote:
>> On 27-10-09 14:31, Sebastian Spaeth wrote:
>>> Current "gst-plugins-base" in org.oe.dev unconditionally depends on
>>> "gnome-vfs" which in turn pulls in stuff like "avahi".
>
>> It's already optional, don't install gst-plugin-gnomevfs
> Thanks for the quick reply.
> I was referring to the fact that the "gst-plugins-base" package directly
> depends on gnome-vfs.
>
> eg.
> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/gstreamer/gst-plugins-base_0.10.22.bb
> contains:
> DEPENDS += "libtheora alsa-lib libsm virtual/libx11 freetype gnome-vfs
> libxv"
>
> This does not look very optional to me. I keep thinking that there must
> be something very obvious that I have missed.

Yes, something along the lines of "build time dependency != runtime 
depency" or in OE speak "DEPENDS != RDEPENDS".

Glibc has qemu in DEPENDS, does that show up on your freerunner?




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-10-27 14:31 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-27 13:31 gst-plugins-base -> gnome-vfs question Sebastian Spaeth
2009-10-27 13:44 ` Koen Kooi
2009-10-27 13:59   ` Sebastian Spaeth
2009-10-27 14:24     ` Koen Kooi
2009-10-27 13:53 ` Graeme Gregory

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.