Bug 209765 contains an ebuild for a package (pango-graphite) that installs a third-party pango module. The module needs to be installed in a separate directory so we can guarantee, by placing the directory at the end of the pango search path, that it will override the standard pango modules, provided that the font contains the necessary graphite tables. This requires that we have some way to add directories to the load path in the first place. The first attempt in bug 209765 involves installing a pangorc file that sets the necessary path, and setting the PANGO_RC_FILE environment variable via /etc/env.d to make sure that pango-querymodules will use the new path when called by the pango ebuild in pkg_postinst. Besides being rather hackish, this won't work if second ebuild that needs to do the same thing is installed, therefore I have written an eclass and eselect module to help manage the load path more cleanly. As I understand it, policy requires sending new eclasses to the dev mailing list for review. I will do that if the gnome team accepts this approach (unless one of the team members would prefer to do it, I'm happy either way).
Created attachment 144110 [details] pango-module.eclass Possible issue is the call to die in pango-module-get-version, since this function is typically called in a subshell. I'm not sure which versions of which package managers this works in, but I can't see a nice alternative.
Created attachment 144111 [details] pango.eselect-0.1 Issue: eselect modules are supposed to respect the ${ROOT} variable, but I don't see any way to do that for this module. If anyone has any ideas, let me know.
Created attachment 144112 [details, diff] pango-1.18.4.ebuild.patch Patch against pango-1.18.4.ebuild to demonstrate usage of the eclass.
Created attachment 144114 [details] emul-linux-x86-gtklibs-20071214.ebuild.patch Patch against emul-linux-x86-gtklibs-20071214.ebuild to demonstrate usage of the eclass. The src_install is nasty, but it should become unnecessary one the emul package is rebuilt against a pango version that uses the eclass, as then the env.d file would be created by pango and included in the tarball.
Created attachment 144115 [details] pango-graphite-2.3.ebuild Attachment 143820 [details] from bug 209765, modified to use the eclass.
Created attachment 144366 [details] pango-module.eclass Just a few cosmetic changes: use _ instead of - in function names, except for the pango-module prefix, to be more in line with existing conventions. Shorten pango-module_add_modules_path to pango-module_add_path. Move the doc comments for pango-module_version around so the code looks slightly less ugly.
Created attachment 144368 [details, diff] pango-1.18.4.ebuild.patch Update for new function names.
Created attachment 144370 [details, diff] emul-linux-x86-gtklibs-20071214.ebuild.patch Update for new function names.
Created attachment 144372 [details] pango-graphite-2.3.ebuild Update for new function names.
Created attachment 144523 [details] pango.eselect-0.1 Since Pango itself doesn't seem to have any protection against loading binary-incompatible modules except for assuming that they'll be in a separate directory not on the path, add an extra safety check.
Created attachment 144524 [details] pango-module.eclass
Created attachment 144528 [details, diff] emul-linux-x86-gtklibs-20071214.ebuild.patch The src_install here is getting more disgusting by the minute, but it's just to let people test without having to rebuild the whole emul package.
David, it's impossible to commit eclasses into sunrise overlay, but probably it'll be not hard to move eclass functions into ebuild and live without eclass until gnome herd starts to maintain some (probably this) solution for pango modules.
is this still of actuality ?
(In reply to comment #14) > is this still of actuality ? > As far as I can tell it's still applicable to the latest version of pango (it doesn't help that the NEWS file in git is out of date, but I don't see any obvious sign of either a native way of handling multiple directories better or built-in graphite support (the only external pango module that I'm aware of / interested in)). The media-libs/silgraphite package in the tree does optionally build the pango module, but it doesn't appear to do anything to register it in the pango.modules file (I don't have it installed right now so I'm not totally sure). I seem to remember mentioning it to aballier a while back, but I don't remember the details. This bug would provide a way of handling that. That said, there's been pretty much no interest so far, so it's up to you if you care.
