On 12.8.2013 2:10, Bruce Dubbs wrote: > Armin K. wrote: > >> Yeah, but KDE 4 uses CMake which (IMHO) isn't that friendly with known >> env vars (see the phonon thread on -support). Also, see KDE instructions >> which add few switches to find qt in non standard prefix or install >> stuff into correct qt prefix and they wouldn't be needed if Qt is built >> into one standard place. I dislike the idea and I won't support it. You >> can, I won't get in your way. > > That's fine. We'll let the users decide. > > -- Bruce >
"Rather than offering you the illusion of the free choice, I'll take the liberty of choosing for you." The quote is from Half Life 2, but it partialy describes what we currently should do. We offer a choice, which can result in several combinations from which most of them were never tested, so it is more prone to errors. From my point of view, we should only test *one* combination and then make everything else assume what was used. Everything else should not be our concern. I remember an article which sort of discussed "freedom of choice". It was describing a situation for a desktop, where user was granted with a freedom (not) to use pulseaudio. Developers designed the desktop components to work with pulseaudio but provided support for ALSA (which should've been totally relaced with pulse, but they wanted to offer their users a choice). Users, of course, hit several bugs where they didn't want to use pulseaudio because they had sound configurations not tested by developers or were hit by some other bugs. The writer described that "freedom of choice" doesn't actually mean users can choose whatever they want, but it means that developer has actually a choice to use whatever they want to make things work (not quite what was said there, but it should at least explain the point). That said, as an editor (think developer), I've also a choice of supporting a single, well tested setup. I consider everything else an experiment by the user who, I assume, should've been prepared for things that broke. Installing a library over the existing library which is currently being used is user's mistake, no ours. We shouldn't bother to support such setup. We don't offer package management, we shouldn't care for updates. That should be up to user. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
