[blfs-dev] [blfs-book] r11616 - trunk/BOOK/x/lib
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
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
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