It's not a build requirement for blender is it?
The reason it is a problem is that yafray 0.0.6 requires gcc3, and this doesn't allow us gcc 2.95.3 users to upgrade to blender 2.32.
At the moment I have to inject yafray, which is a rather inelegant solution.
Could this perhaps become a USE flag?
Steps to Reproduce:
I'm not sure why it's a dep either, because yafray is simply an external renderer from what I understand.
The problem I'm having now is 1) I don't use yafray 2) yafray does not compile here, meaning I cannot install blender-2.32.
Any progress on this, anybody?
blender appears to build & work fine (not an experienced blender user) with yafray dependency removed from ebuild... could edit the ebuild & use overlay so as not to build yafray... I'm not sure if there's a suitable USE flag for this, at least there are none that appear to be obvious candidates to me.
I'm going to take this bug for right now. Once I figure some important things out, I'll re-assign to graphics.org for them to deal with the commit issues.
I'm going to do the compile.. but I first want to make sure that leaving out yafray will not hinder rendering capabilities at all. Pointless for it to be optional if it lacks the proper rendering functions. I do, however, feel positive that it won't.
Ok, It's definate that yafray is indeed optional. I say this with the following logic:
a) It compiles without it
b) Upstream says nothing about it being an integrated part
c) Using it without yafray installed creates no sort of crash
d) It does not hinder the default rendering functionality
As far as whether to keep it that way, It's more of a guess than anything else that yafray will remain an optional component for upstream. This instance it's safe to say it is. I'm going to post the ebuild .diff and re-assign to email@example.com.
Created attachment 34030 [details, diff]
Blender 2.32 diff
More than one year passed since last comment on this bug, and nothing has been
done. Yafray must be one optional dependency of blender.
*** Bug 145251 has been marked as a duplicate of this bug. ***
still (more of) an issue since yafray wont compile with 4.3 either!
any reason this is still a dep?
at least let's have it as an default off USE option.
yafray is warmly suggested, I don't like the idea of having it as an optional dep.
Give me reasons why it should.
PS gcc-4.3 doesn't exist yet
(In reply to comment #10)
> yafray is warmly suggested, I don't like the idea of having it as an optional
> dep. Give me reasons why it should.
Because blender works flawlessly without yafray.
I notice that in 2.43 the dependency on yafray has been completely removed.
I definitely think this should be a USE-flag, probably off by default. My reasons for this are that yafray is not useful on its own (it needs a modeling program), and so it should be installed as a dependency of another program. Also, not having to manually install optional deps is an advantage over e.g. ubuntu.
There are other packages in portage which employ USE flags to install runtime plugins.