|Summary:||media-gfx/blender bogus dependency on media-gfx/yafray|
|Product:||Gentoo Linux||Reporter:||Robert Scott <bugs>|
|Component:||New packages||Assignee:||Luca Barbato <lu_zero>|
|Severity:||minor||CC:||chriswhite, denilsonsa, f.mayer, graphics, telefrancisco|
|Package list:||Runtime testing required:||---|
|Attachments:||Blender 2.32 diff|
Description Robert Scott 2004-02-21 13:14:30 UTC
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? Reproducible: Always Steps to Reproduce: 1. 2. 3.
Comment 1 FieldySnuts 2004-03-05 06:31:29 UTC
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?
Comment 2 hollywoodb 2004-06-21 11:30:08 UTC
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.
Comment 3 Chris White (RETIRED) 2004-06-23 23:49:43 UTC
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.
Comment 4 Chris White (RETIRED) 2004-06-24 00:16:10 UTC
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.
Comment 5 Chris White (RETIRED) 2004-06-24 00:18:50 UTC
Created attachment 34030 [details, diff] Blender 2.32 diff
Comment 6 Denilson Sá 2005-11-29 10:35:12 UTC
More than one year passed since last comment on this bug, and nothing has been done. Yafray must be one optional dependency of blender.
Comment 7 Jakub Moc (RETIRED) 2006-08-27 05:44:02 UTC
*** Bug 145251 has been marked as a duplicate of this bug. ***
Comment 8 genbug 2006-12-18 07:22:24 UTC
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. thx
Comment 9 Jakub Moc (RETIRED) 2007-06-30 21:49:25 UTC
Comment 10 Luca Barbato 2007-06-30 22:13:19 UTC
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
Comment 11 Denilson Sá 2007-07-01 03:16:25 UTC
(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.
Comment 12 Erlend Davidson 2007-12-27 12:13:06 UTC
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.