externalized libraries - rationale for not optional

[Seb Ruiz]

2009/4/5 Caleb Cushing <xenoterracide at gmail.com>:
> I'd like to hear the rationale for not making all the recently split
> libraries not optional for people. So far what I've been told is that
> amarok will compile without them, but functionality will appear
> broken. I'd love to see these things be purely optional modules,
> although not recommended disabled at the distro level (with maybe the
> exception of damn small or something ;) ) but for distro's like
> gentoo, being able to strip them out using use flags, or people just
> building from source, it'd be great (without having broken bits of
> UI).
>
> I'm just curious why amarok devs seem so against this.

We are trying to provide a complete experience when using Amarok. I
know you're going to come back and say something about "choice,
choice, choice", but in reality it's the people that like to choose to
disable functionality that come back and complain that the
functionality that they are looking for doesn't exist.

Making it worse, you get non-official packagers (who are awesome and
do great jobs) who decide to create a package for themselves and then
publish them. When they create custom packages and don't specify
functionality which has been compiled in, it is us that cop the flack
for the problems.

Consider that two months ago most of our dependencies were actually
bundled with Amarok proper. We've broken them out into taglib-extras,
going for liblastfm etc.

Why are you now so determined to have them as optional dependencies?

fwiw - Amarok shouldn't appear broken if a plugin isn't found at
runtime. It should behave nicely, and if you can show us where this
happens I'm sure we'd be happy to fix where possible.

>
> --
> Caleb Cushing
>
> http://xenoterracide.blogspot.com
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok
>



-- 
Seb Ruiz

http://www.sebruiz.net/
http://amarok.kde.org/