On 12/29/2011 09:06 AM, Michał Górny wrote: > On Thu, 29 Dec 2011 08:50:11 -0500 > Mike Gilbert wrote: > >> On 12/29/2011 08:41 AM, Michał Górny wrote: >>> On Thu, 29 Dec 2011 08:08:26 -0500 >>> Mike Gilbert wrote: >>> >>>> This patch allows python_mod_optimize to be used in cases where a >>>> different set of python modules is installed depending on the >>>> python abi. >>>> >>>> For example, dev-python/feedparse-5.1 (not yet in the tree) >>>> installs the _feedparser_sgmllib.py module only in python-3*. >>> >>> Could you paste some example on how it is supposed to be used? >>> >> >> Sure. Borrowed from feedparser-5.1.ebuild in Progress: >> >> pkg_postinst() { >> python_mod_optimize -A "2.*" feedparser.py >> python_mod_optimize -A "3.*" feedparser.py _feedparser_sgmllib.py >> } >> >> pkg_postrm() { >> python_mod_cleanup -A "2.*" feedparser.py >> python_mod_cleanup -A "3.*" feedparser.py _feedparser_sgmllib.py >> } > > Ok, now that I see it, I think you're inventing a really big hammer to > get rid of a single mosquito. > I don't think the hammer is really that big; it seems like a relatively small extension to me. The code for checking ABI patterns is already there, this just wires it up to a couple of additional functions. I actually think it would make more sense to call python_mod_optimize using python_execute_function, but I think that would require a backward-incompatible API change. > On the other hand, I don't think I can think of a good per-ebuild way > to handle this. I'd rather start by pinging upstream not to pollute > global namespace and install a package instead; even if it supposed to > contain __init__.py only. > That would take care of this specific package, yes. However, I still think it would be nice to have a workaround available.