Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

Thomas Orgis (thomas-forum AT orgis.org) wrote [08.04.13 08:51]:
> 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.

What functionality does mpg321 provide that mpg123 does not? Would it
not be feasible to deprecate mpg321 in favor of mpg123 now that it is
under an official oss license? I can understand that some things will
require mpg123 instead of mpg321, but I don't know of any that would
require mpg321 over mpg123 (please enlighten me :D).

-- 
Justin "flux" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpz9nUX51IJi.pgp
Description: PGP signature