Why does amarok depend on ASF/MP4 support?

[Jeff Mitchell]

Andreas Pakulat wrote:
> On 29.09.09 23:46:11, Andreas Pakulat wrote:
>> On 29.09.09 19:26:30, İşbaran Akçayır wrote:
>>> Andreas Pakulat wrote On 29-09-2009 19:03:
>>>> Hi,
>>>>
>>>> I've just had to update taglib to 1.6 for juk, just to find out that amarok
>>>> doesn't build with a standard taglib as it checks for MP4/ASF support in
>>>> taglib. Why is this not optional? I don't have any asf or mp4 files, why
>>>> do I need to be bothered with that?
>>> This was already answered in this mailing list, to summarize, reason for 
>>> this is mostly to force packet maintainers in different distros to 
>>> compile asf/mp4 with taglib, thus giving all amarok users the same 
>>> amarok with same abilities.. its nothing that bad at all, you'll just 
>>> have to pass two words to taglib configure options. ( -DWITH_ASF=On 
>>> -DWITH_MP4=On )
>> Then why doesn't taglib enforce asf/mp4 support? If its supposed to be
>> shipped with that, there's no reason to provide an option. Thats just
>> useless bloat on the cmake files and confuses people that build from
>> source and don't know in-depth all of the deps (And I only build taglib
>> from source because 1.6 is not yet available here).
> 
> Heh, I should aptitude update more often, 1.6 is available in unstable
> already.. Still I think taglib should just not make these options
> available if apps using taglib need it.

The reason it's an option, and turned off by default, is because when it
went into TagLib, some distro package maintainers whined about possible
license and/or legal issues. Keep in mind that this is the same exact
code that had been in mutagen/amarok for *years*.

Eventually the Fedora legal team did a review, which seems to have made
them + everyone else happy -- plus it was pointed out, whenever asked,
that they had been shipping that code for forever and there was no
reason at all for balking at it suddenly just because it goes into a new
library. However, the
it's-an-option-at-all/it's-an-option-and-off-by-default status didn't
get changed in TagLib before release. So we were left with a situation
where suddenly you have a TagLib that, by default, is less capable than
the code you were shipping with before -- and we didn't trust all the
distros to enable these options if left to their own devices. So after
some discussion, we decided to just force the dependency so that the
distros would properly package it.

It's not really any different than all the other formats TagLib supports
that many people don't use (do you have Musepack files? Thought not), so
there isn't much argument for "I don't use it, so I don't see why I
should be forced to include it". It's just visible because of the
configure checks that IMHO should have been done away with (but I forgot
to pester the TagLib guys before release to do it  :-(  ).

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/amarok/attachments/20090929/a1b21122/attachment.sig>