On Tuesday 28 September 2010 23:40:56 Michael Scherer wrote: > > Macports and emerge are more flexible because they compile packages. > > Ie, some packages are inflexible. They requires strict dependency. > For exemple, mplayer requires glibc, and this cannot be changed. > > Some have compile time option ( --with, --without at ./configure ). > > Mplayer can be compiled without libvorbis support, but you need to > recompile it to enable it if needed later. This is quite annoying for > most users, so usually, the packager have to choose, and in mandriva, we > usually enable this, as most people will prefer features, and those that > have specific requirement are usually able to fix the issue themselves > ( or would use another distro like gentoo, we cannot target every > possible use case ) > > And some have runtime options ( ie a plugins system ). Mplayer is not > like that, but totem ( based on gstreamer ) is. Ie, you can install > totem, and it will not automatically pull every gstreamer plugin to read > every file. > > Packager usually try to split plugin in separate rpms, but then you have > to make a choice, ie do we want the plugin to be installed by default or > not ? It is a packager choice usually. > That makes sense of my confusion, thank you. The single most annoying example of the packager's choice for me in the last few Mandrive releases has been the dogged insistence of the packager that I must have Pulse Audio installed or lose the whole of KDE (and presumably Gnome too). To get rid of it completely I must delete the last few remnants "manually" or I am caught in the unreal dependency trap. > > If you fill there is excessive requirement on a package, feel free to > ask the packager his opinion, or open a bug. But I would recommend that > you first take some time to understand how it work before opening lots > of bugs regarding this .
I have been developing "workarounds" as required for the last few releases, but it has been getting harder to achieve cleanly on 2010.0 and 2010.1 . From your explanation above I can see that an early decision to prefer only consumer grade sound systems on the desktop has probably introduced a hard dependency on Pulse for some key KDE (and Gnome?) component. I would imagine that removal of Pulse causes the whole house of cards to collapse due to the indirect dependencies of KDE components on Pulse. I wouldn't presume to call this a bug. After all, it is my decision to prefer a responsive low-latency efficient sound system that I nearly understand over the experimental and sluggish Pulse add-on layer which only seems to cause me greater problems. You have given me hope that if I can learn enough about how rpms work I might be able to find the offending KDE package and re-package it for use on my machines without the "dependency". This does raise another question though. If KDE works perfectly well with Pulse deleted from the system, then how can Pulse be a genuine "dependency"? That's a rhetorical question. When I find the faulty package I will contact the packager and discuss it with him as you suggest. Richard
