alsaplayer can use libid3tag if it is installed. The current ebuild does not reflect this in any way. This means that if a user does not already have libid3tag installed, his alsaplayer will lack the respective features without the user knowing that he could have had those features. It also means that when building a package list that includes libid3tag and alsaplayer the resulting alsaplayer will depend on build-order aspects that are beyond the user's control. I suggest to add libid3tag to the deps when the mad useflag is enabled. Reproducible: Always Steps to Reproduce:
Haven't touched alsaplayer for a while now... but I'll have a look. Just running `emerge --sync` now... give my aging PII laptop a moment to build and run some tests, and I might just be able to make the required adjustments.
Fixed in v0.99.80-r1: I set up a new local USE flag 'id3tag' to enable/disable ID3 support. After reviewing where it got used, and the ldd output... I realised it was actually the FLAC input driver, that uses libid3tag, not the MP3 driver. Behaviour otherwise should be as previous... just now the user can _actually_ disable ID3 support if they wish, or have the library pulled in as a dependency.