Re: [gentoo-user] media-gfx/blender-2.71 dependencies

[List Reader <gentooglelist@gmail.com>]

On Thu, Jul 10, 2014 at 05:31:51PM +0200, Alan McKinnon wrote:
> On 10/07/2014 13:51, Stroller wrote:
> > 
> > On Thu, 10 July 2014, at 4:11 am, List Reader <gentooglelist@gmail.com> wrote:
> >> ...
> >> What does it mean to satisfy >=dev-python/chardet-2.2.1?
> >>
> >>
> >> equery g =dev-python/chardet-2.2.1
> >>
> >> * Searching for chardet2.2.1 in dev-python ...
> >>
> >> * dependency graph for dev-python/chardet-2.2.1
> >>  `--  dev-python/chardet-2.2.1  amd64 
> >>     `--  dev-python/setuptools-2.2  (dev-python/setuptools) amd64
> >>     [python_targets_python2_6(-)? python_targets_python2_7(-)?
> >>     python_targets_python3_2(-)? python_targets_python3_3(-)?
> >>     python_targets_python3_4(-)? python_targets_pypy(-)?
> >>     -python_single_target_python2_6(-)
> >>     -python_single_target_python2_7(-)
> >>     -python_single_target_python3_2(-)
> >>     -python_single_target_python3_3(-)
> >>     -python_single_target_python3_4(-) -python_single_target_pypy(-)]
> >>        `--  dev-lang/python-2.6.9  (>=dev-lang/python-2.6.8-r3)
> >> 	M[package.mask] 
> >> 	   `--  dev-lang/python-2.7.6  (>=dev-lang/python-2.7.5-r2)
> >> 	   amd64 
> >> 	      `--  dev-lang/python-3.2.5-r3
> >> 	      (>=dev-lang/python-3.2.5-r2) amd64 
> >> 	         `--  dev-lang/python-3.3.3
> >> 		 (>=dev-lang/python-3.3.2-r2) amd64 
> >> 		    `--  dev-lang/python-3.4.1  (dev-lang/python) ~amd64 
> >> ? 
> >>
> >> This is getting messy, I didn't think I would need so many unstable
> >> packages. 
> > 
> > I'm very confused, too. 
> > 
> > =dev-python/chardet-2.2.1 offers to emerge just fine on my system, but when I try to emerge Blender I get a similar mess to you.
> > 
> > It seems to be related to this PYTHON_SINGLE_TARGET business.
> > 
> > I understand that PYTHON_TARGETS means "build for this version of Python" but am not familiar with the single target part. 
> > 
> > Perhaps someone else can explain?
> 
> 
> The python targets are an expanded USE which is usually set in the
> profile but can be over-ridden in make.conf. My emerge --info shows:
> 
> PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3
> 
> As I understand it, PYTHON_TARGETS lists all the available python
> versions that ebuilds may use. If an ebuild is coded to use one in the
> list, then great and the build proceeds.
> 
> PYTHON_SINGLE_TARGET defines the python version an ebuild must use if it
> only wants python and does not specify a version.
> 
> This all applies at build time so it's not quite the same thing as
> "eselect python" which specifies what happens at *runtime*
> 
> The best way to maintain this is to let the profile do it (which is why
> most folks don't have any of this in make.conf). You can over-ride the
> profile but then the user must maintain the list[1].
> 
> If I do this:
> 
> PYTHON_TARGETS="python2_7 python3_3 python3_4" emerge -pv blender
> 
> then I get one last error about USE="gflags" for dev-cpp/glog, adding
> that to package.use makes portage happy. SO I think the OP just needs to
> add this to make.conf:
> 
> PYTHON_TARGETS="python2_7 python3_3 python3_4"
> and then tweak package.use if necessary
> 
> > 
> > Does this mean OP should have no other version of Python on his system, but 3.4.x?
> 
> No, it means he needs to tell portage that 3.4 is available for ebuilds
> to build against.
> Confused? Yeah. me too.
> 
> 
> 
> 
> 
> 
> [1] I recall a thread over a year ago where this was explained and I
> found the quote I remember:
> 
> If you are running a modern system with only Python 2.7 & 3.2 installed,
> then you don't have to do anything. The defaults will simply fit you,
> and let you keep your system up-to-date when new Python versions are
> deployed. However, if you'd like to use another set of Python
> implementations, you will need to set PYTHON_TARGETS in your make.conf
> file appropriately.
> 
> It's referenced here:
> https://forums.gentoo.org/viewtopic-t-946824-start-0.html
> 
> 
> To be honest, I'm starting to find Gentoo is being too bloody clever for
> it's own good, introducing complexity in an effort to get portage to
> "always do the right thing", whatever "right" may be in this context.
> 
> We have this python stuff, we have subslots (together with the portage
> output from 6 months ago that no living person ever understood) and
> recently portage is starting to make weird choices for people due to the
> use of
> || ( )
> in ebuilds.
> 
> 
> -- 
> Alan McKinnon
> alan.mckinnon@gmail.com
> 
> 

"As I understand it, PYTHON_TARGETS lists all the available python
versions that ebuilds may use. If an ebuild is coded to use one in the
list, then great and the build proceeds."

Yes! Yes! Thank you. Thats what I thought.

"This all applies at build time so it's not quite the same thing as
"eselect python" which specifies what happens at *runtime*"

Ah! I see.

"https://forums.gentoo.org/viewtopic-t-946824-start-0.html"

Yeah! What he said.

"No, it means he needs to tell portage that 3.4 is available for ebuilds
to build against.
Confused? Yeah. me too."

emerge =dev-lang/python-3.4 ? Why not? I've got three slots already.

"SO I think the OP just needs to
add this to make.conf:

PYTHON_TARGETS="python2_7 python3_3 python3_4"
and then tweak package.use if necessary"

Okay, I see. Thank you so much. Soo so much. I thought I was going round
the twist, or hopelesly ignorant. I couln't understand why emerge didn't offer me
--autounmask-write, so I could dispatch-conf and move on. I was having
similar problems with media-gfx/freecad and some others, but eselecting the
apropriate target/slot thing made it go. Okay, that's it for today. My
eys hurt. I'll do it in the morning. you guys are great. I'm going to bed.

(Yawn) Cinder