Summary: | =x11-libs/pango-1.36.3-r1 - temp/environment: line 3593: x86_64-pc-linux-gnu-pango-querymodules: command not found | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Förster <Dessa> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | multilib+disabled |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | environment file |
Description
Robert Förster
2014-04-20 21:43:55 UTC
Created attachment 375398 [details]
environment file
@multilib, multilib-minimal.eclass and cmake-multilib.eclass currently run multilib_prepare_wrappers() only when the number of ABIs is >1. This makes running wrapped tools in pkg_postinst bit more complicated than it needs to be... By the way, you can guess who actually requested us to do it like this... Thinking about it more, I guess we can replace the 'no of impls' check with dumb [[ $COMPLETE_MULTILIB ]] check. Assuming our non-multilib users don't mind seeing /usr/include/$CHOST. This should eventually be addressed at the eclass level, but we need a fix for pango in the tree right now. Thanks for letting us know about the problem! +*pango-1.36.3-r2 (20 Apr 2014) + + 20 Apr 2014; Alexandre Rostovtsev <tetromino@gentoo.org> + -pango-1.36.3-r1.ebuild, +pango-1.36.3-r2.ebuild: + Unbreak pango-querymodules postinst call for non-multilib case (bug #508278, + thanks to Robert Förster). (In reply to Michał Górny from comment #4) > Thinking about it more, I guess we can replace the 'no of impls' check with > dumb [[ $COMPLETE_MULTILIB ]] check. Assuming our non-multilib users don't > mind seeing /usr/include/$CHOST. I would suggest a less invasive solution - a function, something like multilib_chost_tool_name(), to get the tool name depending on number of impls. I've got another idea: how about creating ${CHOST}-foo-config -> foo-config for multilib-portage? This would make both names working on multilib-portage systems. I guess this would be ok (read your -dev patches, sounds sane). |