Pretty straightforward; the eclass screws with PATH in the global scope, no reason to do so. PATH already contains (via env.d entry) appropriate addition; yet to find a reason to mangle the PATH like that.
where should I tuck it into to ensure that it's run before every step of the emerge process?
or to elaborate, it's there to ensure the correct binary versions get used when you hve both qt3 and qt4 binaries on your system, as they both have the same names. I don't mind putting in inside a function, I just am not clear on the one to put it inside of.
Brian, why adding redundant directory into PATH, screwed up PATH? It's redundant - ok. But is it a problem anywhere? (just courious - I haven't got into a situation where this could be a problem). Caleb - there is another way for calling qmake in nice and easy way. Just look into this: troll@troll ~ $ qmake -v QMake version 2.01a Using Qt version 4.2.2 in /usr/lib/qt4 troll@troll ~ $ /usr/qt/3/bin/qmake -v Qmake version: 1.07a (Qt 3.3.8) Qmake is free software from Trolltech ASA. troll@troll ~ $ alias qmake='/usr/qt/3/bin/qmake' troll@troll ~ $ qmake -v Qmake version: 1.07a (Qt 3.3.8) Qmake is free software from Trolltech ASA. troll@troll ~ $ /usr/bin/qmake -v QMake version 2.01a Using Qt version 4.2.2 in /usr/lib/qt4 quick and easy explanation : you can just use alias in eclass for qmake and it will solve problems with calling it for systems with both qt versions installed. Cheers, Przemek
that's fine with me. I'm not positive on the impact or that it's completely portable, but it sounds like a good solution.
(In reply to comment #4) > that's fine with me. I'm not positive on the impact or that it's completely > portable, but it sounds like a good solution. should be portable for all qt keyworded archs without a problem (at least I don't see why, it could a problem).
Well... I tried aliases idea and it's not working as I thought it will :/ It would be to really painfull to track all possible problems with portage packages. Brian, could you tell us, why you think that redundant directory in PATH is screwing anything here? (these are only qt3 binaries in this path) Cheers, Przemek
Sorry on the lag, was ignoring gentoo for a while there :) Reasoning provided for the PATH insertion makes sense; tbh I assumed it was just cruft in the class that was no longer needed. Te reason why I pushed for moving to a non global approach is that of env saving/restoration; cleaned eclasses and most of the tree a while back to lay the grounds for full env saving/restoration (iow, global would be ran *once*). In other words, proper location would be pkg_setup for it *if it was required*. Portage unfortunately stops PATH a bit on it's own, thus transitioning now isn't possible. That's the long version; short version, y'all have a valid reason for the mod, thus invalidating this bug. Will resurrect it whenever env crap gets pushed on again. Pardon the noise- again, wasn't aware you had a valid reason for the tweak :)
(In reply to comment #6) > Well... I tried aliases idea and it's not working as I thought it will :/ It > would be to really painfull to track all possible problems with portage > packages. > > Brian, could you tell us, why you think that redundant directory in PATH is > screwing anything here? (these are only qt3 binaries in this path) Yes, it's screwing quite a few packages that inherit both qt3 and qt4 and don't specify full paths to qmake (see Bug 183906 as an example). So: - either we can always require people to specify full path - or Bug 120116 should be finally done.
(In reply to comment #8) > - or Bug 120116 should be finally done. so this one can be closed? :) Cheers, Przemek
(In reply to comment #9) > (In reply to comment #8) > > - or Bug 120116 should be finally done. > > so this one can be closed? :) > > Cheers, > Przemek > From comment #55 by jakub in bug #120116: "Bug #168964 shouldn't be closed until all packages are fixed to use eqmake3/eqmake4 instead of invoking qmake directly. At that point, there'll be no reason to mess with the PATH any more and this should be removed from qt3.eclass." As you can see I've already fixed a couple of packages in portage by submitting modified ebuilds to the maintainers. I think we should convert the whole tree...
(In reply to comment #10) > From comment #55 by jakub in bug #120116: > > "Bug #168964 shouldn't be closed until all packages are fixed to use > eqmake3/eqmake4 instead of invoking qmake directly. At that point, there'll be > no reason to mess with the PATH any more and this should be removed from > qt3.eclass." > > As you can see I've already fixed a couple of packages in portage by submitting > modified ebuilds to the maintainers. I think we should convert the whole > tree... Thx Davide - I missed this. Ok. I'm gonna udpate psi to use eqmake. Do you already look the tree for other pkgs that needs this? Cheers, Przemek
It seems that, since revision 1.31, qt3.eclass no longer modifies PATH... Since the change was done more than a year ago and there have been no complaints, I guess this bug can be closed...
Closed. Thanks for bringing this to surface :)
