Opened 6 years ago
Closed 2 years ago
#12200 closed enhancement (wontfix)
Unify /opt and /usr install paths for QT
Reported by: | DJ Lucas | Owned by: | blfs-book |
---|---|---|---|
Priority: | normal | Milestone: | x-future |
Component: | BOOK | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description ¶
This should occur at next update of QT if possible (unless we are very close to 9.0 release). Original comments:
As an aside, and mostly for Bruce (but others are absolutely welcome to comment), what would you say to unifying the install of QT5, making it match a system install? This breakage in the book brings to the forefront why it might be nice. This would basically mean supplying the following to configure (for both camps):
./configure -prefix $QT5PREFIX-sysconfdir /etc/xdg \ -confirm-license -opensource -dbus-linked \ -openssl-linked -system-harfbuzz -system-sqlite \ -nomake examples -no-rpath -skip qtwebengine \ -archdatadir $QT5PREFIX/lib/qt5 \ -bindir $QT5PREFIX/bin \ -plugindir $QT5PREFIX/lib/qt5/plugins \ -importdir $QT5PREFIX/lib/qt5/imports \ -headerdir $QT5PREFIX/include/qt5 \ -datadir $QT5PREFIX/share/qt5 \ -docdir /usr/share/doc/qt5-&qt5-version; \ -translationdir $QT5PREFIX/share/qt5/translations \ -examplesdir /usr/share/doc/qt5-&qt5-version;/examples &&
Obviously, the above needs to be tested yet, and I wouldn't want to do it until at least the next QT update, but I understand the reluctance to do so WRT how pretty the install looks in /opt.There may be some room to go the other way as well - really, we could drop all of the qt5 suffixes, only headerdir is really invasive in the /usr hierarchy (funny that is the variance that caused the breakage in the book). That would result in, I believe, only headerdir, docdir, and examplesdir being passed in.
Change History (4)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
I think unifying the installation paths is the best here, especially for consistency purposes. What we have right now is rather inconsistent and misleading if you are installing in /usr, but that's just my opinion from a simple glanceover, I've never built in /usr (although I'm not opposed to the idea on another system of mine). The problems described in #12201 are a good example of this. The problems with systemsettings5 not being able to find KCM modules described at http://lists.linuxfromscratch.org/pipermail/blfs-dev/2019-June/036230.html (Although as Bruce notes, this may be a Plasma-specific problem).
comment:3 by , 6 years ago
For users of PM's, /opt installation makes little sense. I'm thinking we can go the other way, however (make the /usr installation match the cleanliness of the /opt install, we only need change the path of the headers in the /opt case to $QT5PREFIX/include/qt5. I recognize the otherwise empty include directory, but this simple change fixes AFAICT and doesn't introduce a mess in /usr. QT's build machinery is really clean compared to other toolkits, IOW, very little chance of breakage. I'm going to revisit this on my next KF5/Plasma pass and report back. I'll post a DESTDIR tree of both.
comment:4 by , 2 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Closing as wontfix as we have a note in the book about how to install in /usr. When we install qt6, it may be a good thing to do.
Reformatting:
I still prefer what we have now as I think it is more clear, but I can be persuaded depending on what others think.
The placement in /opt makes a lot more sense in an LFS environment. An update becomes easy. What I use is:
That retains older versions and reverting is as simple as changing the /opt/qt5 symlink.