[blfs-dev] [blfs-book] r11616 - trunk/BOOK/x/lib

Armin K. krejzi at email.com
Sun Aug 11 17:46:27 PDT 2013

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.

More information about the blfs-dev mailing list