Non-standard directory hierarchy #262

Older ebuilds installed TQt3 mainly to /usr/lib[64], /usr/share, etc as is nowadays standard. This overlay seems to put everything under non-standard /usr/tqt3/ paths and setup the default environment to include those.

Why was this change made? Is there any reason not to stick to the standard paths?

(Apparently by "older ebuilds", I mean ones I changed myself on my personal gentoo overlay. Oops)

Oh no. We just finished off the last bugs in this build of tqt.
There is no particular reason, just like other OSes use a separate directory for tqt.
But if you ask me, it used to be a standard in Gentoo to have multiple versions of desktops built in separate directories. Now you can get a problem if you install Plasma and TDE, and earlier this could be solved with scripts.

I do in fact run Plasma, with a few key TDE applications (mainly KMail and KAddressBook). There's some environment magic involved, but it's at the TDE level, not TQt :)

Yes, I know, there are problems with ksysguard and something else. I mean, that don't need to remake tqt ebuilds if they work great. Of course, if there are different tqt builds, then you need to delete the ~/.qt directory so that the paths match the current tqt build.

By the way, you have a rather problematic assembly of TQT. It's not in vain that I collect mng support for tqt with a plugin. Linking all tqt dependent libraries with lcms-2 is a bad idea. As a result, there are problems with applications using lcms-1. I have already faced such problems.

I decided to bump the EAPI on my existing ebuilds rather than switch to these for now, mainly due to this issue.

It would probably be better to adapt your ebuilds to use standard paths, rather than trying to update mine (eg, for MNG plugin). But I lack the time right now.

In the ebuild, tqt does not have to be changed to the standard paths. With this ebuild, the build will still go well, since the necessary settings are present in this ebuild. All the same, the assembly is carried out through dev-tqt/tqtinterface, and he is in the standard paths.

Take a look at the trinity-cmake package. Currently, the cmake modules required for assembly are moved to separate package and are not available in the sources. Since I did not find anything similar in your overlay, I can say for sure that tdelibs in your overlay is currently ending with an error.

I don't want special tqt paths, even if they work.

(Currently, I have my TDE stuff pegged to an older commit.)

Well, I wish you luck.
Meanwhile, now the assembly in this overlay is working.

The oldest relevant ebuild I have on hand (for qt-3.3.8d, file date Apr. 27 2012) seems to indicate an install path of "/usr/qt/3". In other words, the answer to "why is this set up this way?" is "it's always been this way." The location appears to have been selected sometime before 2005 by the Gentoo KDE devs, and tweaked by someone working on an older version of the TDE ebuild tree, then never touched again.

The location appears to have been selected sometime before 2005 by the Gentoo KDE devs, and tweaked by someone working on an older version of the TDE ebuild tree, then never touched again.

Hmm, a very specific person - @Fat-Zer. This overlay originates from this. I have the oldest tqt ebuild from 2009. Then it was on the x11-libs/qt path.

I think most of it was simply:

-       myconf+=" -xft -xrender -prefix ${TQTBASE}"
-       myconf+=" -libdir ${TQTBASE}/$(get_libdir) -fast -no-sql-odbc"
+       myconf+=" -xft -xrender -prefix /usr"
+       myconf+=" -headerdir /usr/include/tqt3"
+       myconf+=" -plugindir /usr/libexec/tqt3/plugins"
+       myconf+=" -datadir /usr/share/tqt3"
+       myconf+=" -translationdir /usr/share/tqt3/translations"
+       myconf+=" -sysconfdir /etc/tqt3"
+       myconf+=" -libdir /usr/$(get_libdir) -fast -no-sql-odbc"

If you are interested in how it was, then I posted it here.

qt-3.3.8b-r1.ebuild.zip

4.4 KiB

I assumed it was probably Fat-Zer, but didn't have the materials on hand to confirm and was too lazy to fish around on Github. ;)

For the record, I didn't come up with this idea by myself as well: frankly, I've just salvaged main-tree latest ebuilds.