[Mageia-discuss] Package management system

[Richard]

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