Why does amarok depend on ASF/MP4 support?

[Andreas Pakulat]

On 29.09.09 18:26:45, Jeff Mitchell wrote:
> 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),

I actually like disable-options and would certainly make use of them if
they'd be available.

> 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  :-(  ).

So I take it that the next taglib release will remove the option or at
least make it on by default? Or is that something that can't be changed
anymore?

Andreas

-- 
You will pioneer the first Martian colony.