Bug 210884 – New eselect module and eclass for pango modules

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description David Leverton 2008-02-20 15:22:52 UTC]

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).

[Comment 1 David Leverton 2008-02-20 15:24:24 UTC]

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.

[Comment 2 David Leverton 2008-02-20 15:25:37 UTC]

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.

[Comment 3 David Leverton 2008-02-20 15:26:18 UTC]

Created attachment 144112 [details, diff]
pango-1.18.4.ebuild.patch

Patch against pango-1.18.4.ebuild to demonstrate usage of the eclass.

[Comment 4 David Leverton 2008-02-20 15:27:45 UTC]

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.

[Comment 5 David Leverton 2008-02-20 15:28:45 UTC]

Created attachment 144115 [details]
pango-graphite-2.3.ebuild

Attachment 143820 [details] from bug 209765, modified to use the eclass.

[Comment 6 David Leverton 2008-02-22 18:36:10 UTC]

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.

[Comment 7 David Leverton 2008-02-22 18:37:10 UTC]

Created attachment 144368 [details, diff]
pango-1.18.4.ebuild.patch

Update for new function names.

[Comment 8 David Leverton 2008-02-22 18:37:45 UTC]

Created attachment 144370 [details, diff]
emul-linux-x86-gtklibs-20071214.ebuild.patch

Update for new function names.

[Comment 9 David Leverton 2008-02-22 18:38:33 UTC]

Created attachment 144372 [details]
pango-graphite-2.3.ebuild

Update for new function names.

[Comment 10 David Leverton 2008-02-24 19:08:47 UTC]

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.

[Comment 11 David Leverton 2008-02-24 19:09:17 UTC]

Created attachment 144524 [details]
pango-module.eclass

[Comment 12 David Leverton 2008-02-24 19:11:22 UTC]

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.

[Comment 13 Peter Volkov (RETIRED) 2008-12-16 09:24:23 UTC]

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.

[Comment 14 Gilles Dartiguelongue (RETIRED) 2011-01-28 17:11:36 UTC]

is this still of actuality ?

[Comment 15 David Leverton 2011-02-01 19:41:44 UTC]

(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.