Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.