Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Hi folks,

I want some opinions on the situation with the mpg321 and mpg123 spells.

The story started with mpg123 being in z-rejected and mpg321 being in
the main grimoire.
mpg321 created a symlink /usr/bin/mpg123 to itself to act as a drop-in
replacement for a good part of mpg123 functionality.
That naturally made mpg321 conflict with mpg123 but this was not noted
in the grimoire, as mpg123 was not in the Free part SMGL.
There is a provider MPG123 that makes spells that need some kind of
mpg123 depend on either one.

I found these spells in test grimoire depending on the provider:

digitaldj gmusicbrowser gqmpeg ecamegapedal snd ecasound cdbakeoven
asterisk mp3burn nautilus2 cutmp3 burncenter eroaster bashburn 

Now, since some time, mpg123 went back into the main grimoire and so we
have an official, Free spell that creates /usr/bin/mpg123.
It has been decided (long ago) to remove the installation of the mpg123 
symlink
from mpg321, and to actually make the spells CONFLICT for playing safe.
This was decided to be the first step in the transition... the conflict
should have been removed after some time, leaving two independend
spells that do not conflict.

Now, the whole thing happened way back in August 2006.
It's about time to finish the plan --- but hey, I forgot about the
MPG123 provider!

As it is now, mpg321 doesn't really provide MPG123; only for the
programs that look for mpg123 _and_ mpg321 binaries.
So I see some options to fix the situation:

1. Reintroduce the mpg123 symlink to mpg321, keep the conflict.
   In that case, I'd feel inclined to follow Enqlave's suggestion to
   also install a retaliatory symlink to mpg321 with the mpg123 spell.

2. Remove the provider MPG123 and make spells depend on mpg123 spell.
   mpg321 is not really a full replacement for mpg123; only part of the
   features work. There are most probably spells that depend on MPG123
   but actually only work with mpg123 (I suspect asterisk, for example).

3. Keep the provider, make sure depending spells find mpg321 binary
   themselves when mpg123 not there -- potentially needs hacking of
   upstream sources.

Options 2 and 3 would allow to remove the conflict between the spells
and enable installation of both together.
I'd like to have that possibility as there is no technical reason to
have them conflicting and they are not totally redundant, as one may
want to use mpg123-like interface to the MAD decoder.

I think this symlink business is ugly and the reason for it has been
that distributions decided to drop mpg123 from the package list in
favour of mpg321. Now, with a Free mpg123 available in main grimoire,
that reason is gone.
But there may still be reason to use mpg321 on it's own right, so I'd
like to drop the conflict.

I am asking about this business here because I do not want to decide
alone in this matter.
People could judge my objectivity, because -- as some of you may know
-- I'm the current maintainer of upstream mpg123 and admit that I
indeed have my personal opinion on the mpg321-instead-of-mpg123 issue.

So, suggestions about how to improve the current situation? Votes on my
3 options?


Alrighty then,

Thomas.

Attachment: signature.asc
Description: PGP signature