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

Armin K. krejzi at email.com
Sun Aug 11 15:27:42 PDT 2013


On 11.8.2013 23:56, Bruce Dubbs wrote:
> Armin K. wrote:
>> On 11.8.2013 23:24, bdubbs at higgs.linuxfromscratch.org wrote:
>>> Author: bdubbs
>>> Date: Sun Aug 11 14:24:18 2013
>>> New Revision: 11616
>>>
>>> Log:
>>> Add alternate Qt5 build instructions
>
>> I still have no idea why you added these instructions when you still
>> symlink the binaries into /usr/bin. I find it pointless. Since yet
>> nothing uses Qt5 (no desktop and such), it can be easily overwriten
>> without any problems in /usr.
>
> Planing for the future.  I thought about mentioning changing the PATH,
> but decided the user could figure that out.
>

That has several disadvantages currently (the path thing) since most 
apps looking for qmake in path will look for qt version 4.

>> Also, qtchooser won't work for this one.
>
> Really?  I figured that the only thing needed would be to
>

Current instructions.

> cat > /etc/xdg/qtchooser/5.conf << "EOF"
> /opt/qt5/bin
> /opt/qt5/lib
> EOF
>
> That said, I've never liked the 'alternative' scripts.  It's easier to
> just change the PATH.
>

For this, it's enough to set/unset an env var.

> I've also thought about making the path functions in /etc/profile
> persistent.  Then the qtchooser would be simply
>
> pathremove old-qt-path; pathprepend new-qt-path
>
> or
>
> pathprepend alternate-qt-path
> do build
> pathremove alternate-qt-path
>
> Another option would be to just change the /opt/qt symlink, but that
> requires being root.
>
>     -- Bruce
>

And ton of another workarounds, variables and configure/cmake switches 
we don't know yet. More or less, it should be always safe to update the 
package even if it's in /usr since well, such package shouldn't be 
updated if you are running from the Qt5 terminal. (same applies for 
GTK+, Xorg, etc). The trick is, nothing can be updated (by just issuing 
make install and letting the process overwrite everything) without 
consequences.



More information about the blfs-dev mailing list