Usually the 'mad' useflag has been used in ebuilds having optional mp3 support through the libmad library. The 'mp3' useflag was introduced later, but now that we have it, it makes sense to just use 'mp3' for mp3 support, no matter what library is used for the task. Note that 'mad' can have a valid use: to decide whether libmad or another library should be used for mp3 support if the package gives the choice. Currently this is the case only for media-sound/xmms, which does the right thing already. Here are the packages affected: media-optical herd: app-cdr/graveman games herd: games-arcade/stepmania games-engines/scummvm games-engines/stratagus gnome herd: gnome-base/nautilus gnome-extra/gnome-media kde herd: app-cdr/k3b kde-base/akode kde-base/arts kde-base/juk kde-base/kdemultimedia media-libs/tunepimp media-sound/amarok sound herd: media-sound/audacity media-sound/beast media-sound/bossogg media-sound/moc media-sound/mpd media-sound/mpd-svn media-sound/mpfc media-sound/normalize media-sound/quodlibet media-sound/rhythmbox media-sound/sox media-sound/terminatorx gstreamer herd: media-sound/muine media-video/totem video herd: media-video/avidemux media-video/avifile media-video/gpac media-video/mplayer media-video/tcvp media-video/totem media-video/vlc vapier: app-misc/evidence rizzo: media-libs/swfdec
Note: xine-lib-1.0.1-r2 has a mad useflag which is used to enable external mad instead of internal one. That should be left as it is I think.
For avidemux, the mp3 useflag will be misleading, mad is used for decoding; "encode" (aka lame) is used for encoding. I've renamed it for vlc.
It's a nice idea and has been around for a while, but this is more than a mad->mp3 change. It changes the function of USE flags to a goal based form, which really can collide with the controllable nature of packages we provide trough USE flags. I'm not against this, I just want this discussed in a wider context before an action is taken.
(In reply to comment #3) > It's a nice idea and has been around for a while, but this is more than a > mad->mp3 change. It changes the function of USE flags to a goal based form, > which really can collide with the controllable nature of packages we provide > trough USE flags. Indeed. The idea is exactly to follow the trend of having goal-based use flags where appropriate, which in this specific case began when the 'mp3' flag was introduced a few months ago. I filed this bug because in this case there are near to zero conflicts involved in the change mad->mp3, and we get as a result that the way to enable/disable support for mp3s becomes much more user-friendly and intuitive (everyone know what mp3 means, while mad is not a very popular term). Anyway, note this is not high priority and there's no pressure to implement it in given amount of time.
There is no such idea ever pushed in any official way & it is inconsistent with how things are done and as such a bad thing to do ad-hoc. I did not even suggest it is a better idea than having package bound USE flags. I suggest you propose a consistent view on USE handling/naming/interpretation and then make a tree wide usability effort. At this point I'm not about to change known behaviour to something undefined.
updated evidence / scummvm / stratagus
> At this point I'm not about to change known behaviour to something undefined. Ok. But note that there will not be any unified effort towards a more consistent flag namespace anytime soon. It's just impossible, given how much the current list of global flags is heterogeneous and cluttered (the way things are done now cannot be considered consistent). It makes sense to focus on a small list of flags that are most visible to users -- because they are used in more packages, or in more important ones -- and try to make them appear consistent to our users when they have to deal with them.
Please let's discuss that before doing that. bug marked as NEEDINFO.
For example, on mips the mad USE flag is masked because madplay isn't keyworded. mp3 isn't masked because that would disable all mp3 support. But I'm sure there are some packages that have optional mp3 support that works on mips. ;) This is in my oppinion a reason for not changing the flags.
Hmm actually the problem is with libmad, not madplay anyway.
As discussed on irc, i'm changing the severity to enhancement to better clarify the purpose of this bug: it's not intended as an enforcement of some policy. Think of of it just as a suggestion for the ebuild maintainers: each application listed above can optionally play mp3s, and we have a 'mp3' flag that "enables support for reading mp3 files", so probably users would expect that the 'mp3' flag will be used in these cases. I'm just proposing that the ebuild maintainers make use of it. As Sven and Diego pointed out, there can be technical or non-technical reasons to not do it, so each maintainer is free to reject the proposal if he does not deem it appropriate.
media-optical package done.
This bug recently came to my attention, and I should comment before the entire portage tree goes from mad->mp3. Sven mentioned in comment 9 that mad is masked on mips because madplay is not keyworded, but this isn't the real reason. On the mips arch, anything that uses libmad is totally broken. It will just spit out awful static from the speakers if you try to use any sort of mad output. Because of this, I put mad into the mips use.mask, and I changed keywords for libmad and any ebuild that needs mad to -mips. However, the mp3 USE flag *is* valid on mips, and we have no reason to mask it. If everybody changes their ebuilds such that USE="mp3" is the same as USE="mad", then you will essentially be totally screwing over multimedia stuff on mips. See bug #99403 for an example of how we have already been screwed. The use.mask file exists for a purpose. Please don't take away its function and force use to put !mips crap for the libmad dep in every package that uses the mp3 USE flag.