Bugzilla Bug 168964

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 :)