Summary: | app-eselect/eselect-python should set links for libboost_python | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | John (EBo) David <ebo> |
Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | cpp+disabled |
Priority: | Normal | ||
Version: | 10.1 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
John (EBo) David
2014-01-19 12:17:15 UTC
That would would make it really easy for an ebuild developer to be lazy and let a package link with the active version of libboost_python, when they should probably be using the python-r1 or python-single-r1 eclass. I'm not against being lazy, but I wonder what kind of weird problems that might cause. In any case I think this probably belongs in a separate eselect module. I don't think there is any reason to tie the active libboost_python to the active python interpreter. Not to mention that for ebuild use the eclass should manage it and not eselect-python. Should we close this bug then? Yes, I guess so, since we seem to silently agree on not pursuing the problem further. I agree. I figured that the bug is nearly 3 years old and we had found a work around for it... Actually I completely forgot about this bug report until I posted another bug today. Thought it would be good to close it. |