Am Tue, 20 Apr 2010 15:34:21 +0100 schrieb Ananda Samaddar :

Is there some reason that the gstreamer good plugins set needs a whole load of GNOME crap?

http://www.archlinux.org/packages/extra/x86_64/gstreamer0.10-good-plugins/

I've recently switched to XFCE and I'd like to avoid GNOME dependencies. Is it possible to recompile from abs without all these dependencies?

thanks,

Ananda

This is of course possible, the gstreamer ./configure script allows to disable most of the dependency-heavy features. ./configure --help list all possibilities. This for example is the configuration i use: ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ --disable-static --enable-experimental \ --disable-schemas-install \ --disable-gconf \ --disable-hal \ --disable-dv1394 \ --disable-pulse \ --disable-esd \ --disable-esdtest \ --disable-sunaudio \ --disable-osx_audio \ --disable-osx_video \ --disable-flac \ --disable-gst_v4l2 \ --with-package-name="GStreamer Good Plugins (Archlinux)" \ --with-package-origin="http://www.archlinux.org/" || return 1

On 04/20/2010 10:37 AM, Ananda Samaddar wrote:

On Tue, 20 Apr 2010 16:40:27 +0200 Thomas Haider wrote:

...

Am Tue, 20 Apr 2010 15:34:21 +0100 schrieb Ananda Samaddar :

...

Is there some reason that the gstreamer good plugins set needs a whole load of GNOME crap?

http://www.archlinux.org/packages/extra/x86_64/gstreamer0.10-good-plugins/

I've recently switched to XFCE and I'd like to avoid GNOME dependencies. Is it possible to recompile from abs without all these dependencies?

thanks,

Ananda

This is of course possible, the gstreamer ./configure script allows to disable most of the dependency-heavy features. ./configure --help list all possibilities. This for example is the configuration i use:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ --disable-static --enable-experimental \ --disable-schemas-install \ --disable-gconf \ --disable-hal \ --disable-dv1394 \ --disable-pulse \ --disable-esd \ --disable-esdtest \ --disable-sunaudio \ --disable-osx_audio \ --disable-osx_video \ --disable-flac \ --disable-gst_v4l2 \ --with-package-name="GStreamer Good Plugins (Archlinux)" \ --with-package-origin="http://www.archlinux.org/" || return 1

Thanks for that, I'm created a custom PKGBUILD that removes all the GNOME crap, I'm going to upload it to the AUR when it's done.

Ananda

You know, It still amazes me how people will take the position that all associated with Gnome must be 'crap'. No don't get me wrong, I have no arguments with your basic complaint that unnecessary dependencies need not be included with the gstreamer packages. In fact, I agree. However, that notwithstanding, the general premise asserted in the comment "GNOME crap" is just flat wrong. Now I was a KDE guy, did a lot of beta work with KDE4 and also enjoy enlightenment, the 'boxtops', windowmaker and recently Gnome. From first-hand experience, I can tell you gnome is not crap. It is a solid desktop built on the metacity wm that does a great many things right and a handful of things I would do differently if I wrote desktops and wm's, but on balance is an excellent desktop. Not to mention, it is just down right gorgeous: (152k) http://www.3111skyline.com/dl/img/ss/gnome/BlueNightII.scaled.jpg Oh well, at least the gstreamer packages stripped of unnecessary dependencies will be a great addition to AUR. Thank you for that. But no need to deride a desktop just because whoever packaged it last included a few unneeded dependencies :p -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On Tue, 2010-04-20 at 15:34 +0100, Ananda Samaddar wrote:

Is there some reason that the gstreamer good plugins set needs a whole load of GNOME crap?

http://www.archlinux.org/packages/extra/x86_64/gstreamer0.10-good-plugins/

I've recently switched to XFCE and I'd like to avoid GNOME dependencies. Is it possible to recompile from abs without all these dependencies?

thanks,

Ananda Won't xfce be switching to "GNOME crap" like gvfs? :P

On 21/04/10 19:25, Ananda Samaddar wrote:

On Wed, 21 Apr 2010 12:14:56 +0300 Hussam Al-Tayeb wrote:

...

Won't xfce be switching to "GNOME crap" like gvfs? :P

That's only an optional dependency for Thunar if I remember correctly. I'm still trying to find out about that as I don't want to end up with a whole bunch of GNOME libs to run XFCE. If that's the case I might as well go back to GNOME. My main beef with GNOME though is the Shell.

Going off topic... but if you do not want GNOME shell, then do not install it. It sounds like the "old" GNOME panel will still be available as an alternative. Allan

On Wed, 2010-04-21 at 19:28 +1000, Allan McRae wrote:

On 21/04/10 19:25, Ananda Samaddar wrote:

...

On Wed, 21 Apr 2010 12:14:56 +0300 Hussam Al-Tayeb wrote:

...

Won't xfce be switching to "GNOME crap" like gvfs? :P

That's only an optional dependency for Thunar if I remember correctly. I'm still trying to find out about that as I don't want to end up with a whole bunch of GNOME libs to run XFCE. If that's the case I might as well go back to GNOME. My main beef with GNOME though is the Shell.

Going off topic... but if you do not want GNOME shell, then do not install it. It sounds like the "old" GNOME panel will still be available as an alternative.

Allan

gnome-panel no longer uses libgnome(ui) in gnome 2.30 Another good news there is a branch in git that replaces libbonobo(ui) with dbus. I see your point now. gnome-shell isn't usable so you're looking into XFCE. But rest assure gnome-panel/metacity are going nowhere. And it's only going to get better and faster when libbonobo(ui) is out of the window. Gconf is going to be replaced with dconf but not for gnome 3.0

On Wed, 2010-04-21 at 10:35 +0100, Nathan Wayde wrote:

Do you mind listing these Gnome dependencies, or at least your proposed PKGBUILD? I've looked at this and I can see only 2 (gconf and libsoup-gnome). Ofcourse that is based on the assumption that the pacma dependencies are correct(e.g good-plugins depends on x,y,z but only x is listed because it also depends only y and z).

The GNOME dependencies involved: libsoup-gnome libgnome-keyring (gnome-keyring) gconf orbit2 libidl2 I don't consider this as a big problem, and I closed bugs about it before. The libsoup-gnome library adds proxy lookup and password lookup functionality to libsoup. GStreamer can work without it, but it will lose quite some functionality without it. The gconf*sink elements in GStreamer need gconf. Without this, there's no way to configure the audio and video element in a central place. Some applications even ask for this specifically. I listed the gnome-keyring dependency as optional, as it's a fake dependency added to libgnome-keyring. libgnome-keyring needs a keyring daemon, AFAIK the next version of KDE will also get one. In the future, GNOME applications using libgnome-keyring can read passwords from KDE password storage. Libidl2 isn't a big issue either, as firefox already depends on it. I haven't seen much Arch Linux desktop installations without firefox. Note that the hal plugin will get removed soon. The only application I know that could have benefit from this plugin is cheese, but that has been ported to libgudev since 2.30.0.

On 21/04/10 10:52, Jan de Groot wrote:

On Wed, 2010-04-21 at 10:35 +0100, Nathan Wayde wrote:

...

Do you mind listing these Gnome dependencies, or at least your proposed PKGBUILD? I've looked at this and I can see only 2 (gconf and libsoup-gnome). Ofcourse that is based on the assumption that the pacma dependencies are correct(e.g good-plugins depends on x,y,z but only x is listed because it also depends only y and z).

The GNOME dependencies involved: libsoup-gnome libgnome-keyring (gnome-keyring) gconf orbit2 libidl2

I don't consider this as a big problem, and I closed bugs about it before. The libsoup-gnome library adds proxy lookup and password lookup functionality to libsoup. GStreamer can work without it, but it will lose quite some functionality without it. The gconf*sink elements in GStreamer need gconf. Without this, there's no way to configure the audio and video element in a central place. Some applications even ask for this specifically. I listed the gnome-keyring dependency as optional, as it's a fake dependency added to libgnome-keyring. libgnome-keyring needs a keyring daemon, AFAIK the next version of KDE will also get one. In the future, GNOME applications using libgnome-keyring can read passwords from KDE password storage. Libidl2 isn't a big issue either, as firefox already depends on it. I haven't seen much Arch Linux desktop installations without firefox.

Note that the hal plugin will get removed soon. The only application I know that could have benefit from this plugin is cheese, but that has been ported to libgudev since 2.30.0.

I'm guessing that's still only 2 *direct* dependencies and the number of indirect dependencies is surprisingly low from what it sounded like. I guess I jut don't see the big deal(I prefer Gnome, but prefer programming in Qt more than Gtk et al.). This is somewhat similar to people raging that won't use xyz because it depends on Gnome, when the only dependency is glib(which is prolly on their system through Qt anyway).

On 04/21/2010 03:28 AM, Ananda Samaddar wrote:

Yes it was an unfortunate choice of words. I don't think GNOME is crap, I'm just not enamoured with the direction it seems to be headed in, i.e. GNOME Shell. I can do without shiny stuff like that. Previous to my switching to XFCE I was a GNOME user for a very long time. I reckon GNOME 3.0 will be just as much of a PR nightmare as KDE4 was and continues to be.

It frustrates me that core technologies can depend on a long list of dependencies for another desktop environment. Try installing gstreamer0.10-plugins-good if you're not running GNOME and you'll see what I mean.

Ananda

That I agree with 100%. I've moved all my boxes to Arch except my laptops (and a couple of stragglers) which are still running suse 11.0 (due to need of ATI fglrx 8.593 [8-9 release]). On suse I have the old gnome 2.22, on Arch we have gnome 2.30. There are a few quirks with gnome 2.22, but it is solid. At least configuring gnome like I do, I haven't noticed too much different in 2.30. I hope it stays that way. Nobody wants to see a kde4'ing of gnome :p (yes, I guess kde4ing is a lasting verb now...) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

On Wed, Apr 21, 2010 at 10:59:17PM +0800, Ng Oon-Ee wrote:

I appreciate the desire for a minimal system. What I don't understand is the vilifying of packages just because they're part of a standard Gnome install.

That's not the point. According to the definition on the gstreamer website "GStreamer is a library for constructing graphs of media-handling components. The applications it supports range from simple Ogg/Vorbis playback, audio/video streaming to complex audio (mixing) and video (non-linear editing) processing." Fine. Potentially very interesting and useful. But if it depends on things that have *nothing at all* to do with the claimed application domain - security subsystems (keyrings) and configuration programs for a specific desktop (gconf) that, at least in my world, is a sign of *crappy design*. Which seems to invade almost everything Gnome. One is almost tempted to believe that introducing irrelevant dependencies is the essence of the game. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

On Thu, 2010-04-22 at 06:22 +0800, Ng Oon-Ee wrote:

...

Would you prefer the developer reimplement security-authorization and a configuration parser, then? Its not even as if gconf and its editor aren't separated into different packages.

As long as GNOME doesn't start using it, that would be fine. I mean, who wants to use a generic network library that appears to support proxies and authentication storage? I think it's awesome to implement this in each and every application, just because we hate storing passwords in a central location.

On Thu, 2010-04-22 at 00:37 +0200, Philipp wrote:

Excerpts from Ng Oon-Ee's message of 2010-04-22 00:22:24 +0200:

...

On Wed, 2010-04-21 at 22:04 +0200, fons@kokkinizita.net wrote:

...

On Wed, Apr 21, 2010 at 10:59:17PM +0800, Ng Oon-Ee wrote:

...

I appreciate the desire for a minimal system. What I don't understand is the vilifying of packages just because they're part of a standard Gnome install.

That's not the point. According to the definition on the gstreamer website

"GStreamer is a library for constructing graphs of media-handling components. The applications it supports range from simple Ogg/Vorbis playback, audio/video streaming to complex audio (mixing) and video (non-linear editing) processing."

Fine. Potentially very interesting and useful.

But if it depends on things that have *nothing at all* to do with the claimed application domain - security subsystems (keyrings) and configuration programs for a specific desktop (gconf) that, at least in my world, is a sign of *crappy design*. Which seems to invade almost everything Gnome. One is almost tempted to believe that introducing irrelevant dependencies is the essence of the game.

Ciao,

Would you prefer the developer reimplement security-authorization and a configuration parser, then? Its not even as if gconf and its editor aren't separated into different packages.

I don't know what I need security authorization ind a multimedia backend for. I don't know whether gconf is usable without its editor and it doesn't matter really since it stays a gnome thing. Yes, I rather have an application specific config than a DE specific config system.

Gconf is useable without its editor (just browse through the filesystem). This may or may not change in future, I've heard it may move to a database-based thing like currently in KDE. App-specific config is well and good, but more work on the part of the developer. Good software gets re-used, what's the difference between using gconf for your configuration needs and using boost for the 'standard' parts of your code? Or would you prefer to reimplement common mathematical algorithms just to not have to add the boost dependency?

On Thu, 2010-04-22 at 22:37 +0200, Fons Adriaensen wrote:

On Thu, Apr 22, 2010 at 06:22:24AM +0800, Ng Oon-Ee wrote:

...

On Wed, 2010-04-21 at 22:04 +0200, fons@kokkinizita.net wrote:

...

...

"GStreamer is a library for constructing graphs of media-handling components. The applications it supports range from simple Ogg/Vorbis playback, audio/video streaming to complex audio (mixing) and video (non-linear editing) processing."

Fine. Potentially very interesting and useful.

But if it depends on things that have *nothing at all* to do with the claimed application domain - security subsystems (keyrings) and configuration programs for a specific desktop (gconf) that, at least in my world, is a sign of *crappy design*. Which seems to invade almost everything Gnome. One is almost tempted to believe that introducing irrelevant dependencies is the essence of the game.

Ciao,

Would you prefer the developer reimplement security-authorization and a configuration parser, then? Its not even as if gconf and its editor aren't separated into different packages.

No. An application using gstreamer could depend on security subsystems and desktop configuration parsing, and use libraries for that. The audio/video code itself shouldn't.

Unfortunately gstreamer is partly application in that it handles the authorization as well as reads configuration options. On my system ~/.gconf/system/gstreamer/0.10/default/%gconf.xml has the default settings for gstreamer (default audiosink and videosink). Perhaps those should be part of the gnome-media package instead (which depends on gstreamer and provides the gstreamer-properties binary), but what happens when gnome-media is not installed, what defaults would gstreamer fall back on when there ARE no defaults? Perhaps an upstream bug-report?