Tushar Teredesai wrote these words on 12/27/05 00:44 CST: > The fact that the bug was opened indicates that there is atleast one > person out there who installs qt in /usr:) Just to be technically > correct, the bug is because the kernel source uses an inflexible way > of checking for qt installation. So it is not with qt. The correct fix > would be to fix the qt check in the kernel's kconfig target.
Man, at this point, I'm now sorry I brought this bug up as an example of stuff being installed into /usr that is not the default. I'm quite certain that bug #1522, and the ones before it have stretched to more than a year now. Hence, the years (archaic asked about). If I'm mistaken, then so what? The point is that installing something against the maintainers recommendations could bite you in the ass. (archaic wondered how the Qt thing was relevant, hopefully, this is some indication, if not please disregard) Tush, I don't mean anything by this, but you accepted this bug, and assigned it to yourself many months ago. It is still open. I installed Qt just today and it works just fine, including using the make xconfig with the Linux kernel. And you're blaming some glitch in the Linux kernel that Qt installed per the BLFS instructions to install it in /usr is the problem why it doesn't run? Come on... Total crap. If Qt is installed so that the system can find it via the QTDIR env var and the PATH and everything else BLFS says to do, then make xconfig will run. I know, I just did it. And there is a bug (#1522) that says it doesn't work if you have Qt installed in /usr IAW BLFS instructions. I, for one, don't believe the bug. But I'll never me able to test, or close, the bug because I'll never install Qt in /usr. I don't know what to think and at this point give up. Never mind. I realize the discussion was where to install X. I've been saying the default. The default at this point is /usr/X11R6. Until it changes, then everyone is sort of on there own how to do it without encountering problems. Right? Me, I'm not moving to Xorg-7.0 until it is proven to work well. I have no reason to. There's nothing it provides that the current version doesn't do already without the hassle of figuring out the new build method. Is this a cop out? Yes. But, a few months from now, will it really matter? There will be solid instructions, and we can use these to create good BLFS instructions. Until then, I'll just sit back and use what works for me. :-) -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 01:01:01 up 93 days, 10:25, 3 users, load average: 1.34, 0.41, 0.23 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
