I just tried to upgrade to kid3-1.6 (thanks for the bump, btw), but found that it's requires kde-base/kde-l10n now. Prior versions, including 1.5, did not. I really don't need kde-l10n installed for any reason, and I can't find any reason in the changelog why this would all of a sudden be required when *nothing* else on my KDE system requires it, so this is rather puzzling (and annoying :-)). I tried tracking this down, and it appears to be getting forced on by kde4-base.eclass. I'm having trouble following the code, but based on the comment it looks like it's getting flipped on because both EAPI=4 and KDE_LINGUAS="blah" are defined. I'd assume this is appropriate for certain situations if someone went through the trouble to add it to the eclass, but it shouldn't be always required. To use my case as an example: # emerge -pv kid3 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] kde-base/kde-l10n-4.6.2 USE="handbook (-aqua) (-kdeenablefinal) (-kdeprefix)" LINGUAS="-ar -bg -ca -ca@valencia -cs -da -de -el -en_GB -es -et -eu -fi -fr -ga -gl -gu -he -hi -hr -hu -ia -id -is -it -ja -kk -km -kn -ko -lt -lv -mai -nb -nds -nl -nn -pa -pl -pt -pt_BR -ro -ru -sk -sl -sr -sv -th -tr -uk -wa -zh_CN -zh_TW" 0 kB [ebuild N ] media-sound/kid3-1.6 USE="flac handbook kde mp3 taglib vorbis (-aqua) (-kdeenablefinal) -mp4" LINGUAS="-cs -de -es -et -fi -fr -it -nl -pl -ru -tr -zh_TW" 1,444 kB So, yes, LINGUAS support in kid3 exists, but I don't use it at all, and as such kde-l10n shouldn't be a requirement. I think a more appropriate check would be to determine if any LINGUAS flags are enabled rather than just checking to see if the variable exists. If one or more flags are enabled, then l10n support is wanted/needed; otherwise, it's a superfluous dependency. Reproducible: Always
Fixed in eclass for both overlay and main tree.
