Bug 12392

(In reply to Malo Deniélou from comment #0)
Well, something wrong. As you can see in specfile, mate-settings-daemon-pulse conflicts with mate-settings-daemon-gstreamer:

%define          source_name mate-settings-daemon
.
.
.
Conflicts:       %{source_name}-gstreamer = %{version}-%{release}


Ahh... While Colin bumped rel for pulse package, it stayed same in gstreamer package. Thus they' re not conflicted. I' ll fix this.

You can probably just kill the version conflict. i.e. can't you just have:

Conflicts:       %{source_name}-gstreamer

Perhaps not seeing the reason for this tho'. :)

(In reply to Colin Guthrie from comment #2)
You may right. But i prefer release bumping for mate-settings-daemon-gstreamer and added a comment for packager both specfiles.

Anyway, asked for freeze push for mate-settings-daemon-gstreamer-1.6.2-2.mga4 which should fix this problem.

Ths is wrong!!!
The conflicts tag should be relaxed instead!

(In reply to Thierry Vignaud from comment #4)
OK. I reverted it and removed release tag from both packages in provides/obsoletes/conflicts.

Version tag should be in place, both packages come from same source. BTW, any of you can tell me if i can do this in one specfile. They come from same source but compiled with different configure flags and mostly provide same files...

That's still wrong.
Since the path of libsound.so is not dependent of the version, it's better to have the conflict stated independently of the version. You shouldn't change the provides, etc.

(In reply to Malo Deniélou from comment #6)
Why? They both provides mate-settings-daemon package. If i don't remove release tag from provides, doesn't urpmi try to install mate-settings-daemon-pulse over gstreamer package, does it?

For this kind of preference, I think it's better to use an unversioned provide and then tell meta-task about the preference.

Another way way be to use the update-alternatives system to make both packages non-conflicting and use a symlink structure based on a "priority" to ensure the right files are linked in. It's maybe a bit convoluted if too many files differ, but perhaps the differences are contained in just one module?

Regarding building both from the same package, most software supports a "build" dir 

e.g. rather than just:
%configure --args

you may be able to do:

mkdir pulse
pushd pulse
%configure --args
popd

mkdir gst
pushd gst
%configure --otherargs
popd


Then for install, I'd something similar for install but just install one of them, move the differing files to an "alternative name" (e.g. with -pulse- added to the name, and then do the other install. It will overwrite things but that's OK. Then rename the new conflicting file to have -gst- in it's name. After that it's a matter of ensuring you call the appropriate alternatives code in %post scripts.

Feel free to ask for more details. You can see an example in the pulseaudio spec for the "client-config" sub package and (and get a feel for how it works with e.g. "update-alternatives --display soundprofile")

Oh actually, while the above advise is correct, I didn't actually see the wood for the trees regarding the update-alternatives stuff! This is actually something you should just make part of the soundprofile logic rather than your own alternatives. e.g.

Something like this.

Say you have a file:
 /usr/lib64/mate-settings-daemon/libmedia-keys.so
that differs for PA vs. GST.

As part of the build mentioned above, you should end up with:
 /usr/lib64/mate-settings-daemon/libmedia-keys-pulse.so
and
 /usr/lib64/mate-settings-daemon/libmedia-keys-gst.so

after doing some manual renaming during the %install phase.

What you should do then is (adapting for %buildroot inclusion)

mkdir -p /etc/sound/profiles/{alsa,pulse}/mate/%_lib
ln -s /usr/lib64/mate-settings-daemon/libmedia-keys-pulse.so /etc/sound/profiles/pulse/mate/%_lib/libmedia-keys.so
ln -s /usr/lib64/mate-settings-daemon/libmedia-keys-gst.so /etc/sound/profiles/alsa/mate/%_lib/libmedia-keys.so

and then finally:

ln -s /etc/sound/profiles/current/mate/%_lib/libmedia-keys.so /usr/lib64/mate-settings-daemon/libmedia-keys.so


This basically hooks up your lib into the sound profile logic. Whenever someone disable PA in draksound the libs will magically flip over because the path to the /etc/sound/profiles/current/ folder changes.

I don't think the above will give you any rpmlint warnings (although it might), but it should be the nicest structure overall IMO.

Again feel free to poke me on IRC or the ML for more advice. This is somewhat beyond the scope for this bug (although it is related) :)

Malo, fixed mate-settings-daemon-pulse and mate-settings-daemon-gstreamer already in repos. Should we close this bug report?

If it's fixed in mga4, then it can be closed.

Already fixed for Mageia 4 before release. Closing.

Status: NEW => RESOLVED
Resolution: (none) => FIXED