GNOME Bugzilla – Bug 355985
Handling of directories in Pango/ModuleFiles
Last modified: 2015-08-15 03:08:57 UTC
Hi, I'll attach a patch which permits loading all *.modules files from directories listed in Pango/ModuleFiles. The rationale for this feature is to permit the pango library to be functional as soon as it is unpacked, before the package's postinst had a chance to run. This is necessary when for example you're using a frontend relying on Pango to upgrade your system. Bye,
Created attachment 72797 [details] [review] Processes all *.modules files in directories listed in Pango/ModuleFiles
Created attachment 72798 [details] [review] Adds LIBDIR/MODULE_VERSION/module-files.d to Pango/ModuleFiles (needs 72797)
I don't understand what you are trying to achieve. Specifically, can't this be done using the PANGO_RC_FILE env var? See how this is done in pango/examples/ for example.
(I didn't mention it, but this is for the Debian packages of pango.) Generally speaking, multiple packages may provide Pango modules, with of course the Pango package. What was done in the past was to have all modules listed in the /etc/pango/pango.modules file. To achieve this, the postinst of Pango and of packages providing Pango modules would do something like pango-query-modules > /etc/pango/pango.modules. This scheme had some important problems: - FHS compliance: /etc is supposed to hold configuration files, not generated data, and would the use have changed /etc/pango/pango.modules, he would lose his changes after installing a new package or simply upgrading Pango - Pango applications would only be functional after the initial generation of /etc/pango/pango.modules (this is the bug I mention in the report) (- to some extend, for multiarch, it is a problem to list architecture dependent data in an architecture independent path; this is a pet goal, so I wont enter into too many details here, and there are other solutions to this proble anyway) One instance of the second problem appeared in Ubuntu: https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/41297 The bug happens because the Debian configuration frontend for GNOME is started after Pango is unpacked, but before its postinst, so before we have a pango.modules in place. The solution in Ubuntu was to move the location for pango.modules to be in /var, and ship a pre-generated file in this place, then update it in the postinsts as usual. This only solves the problem for Pango, and doesn't solve the problem for upgrades of Pango with differents MODULE_VERSION values. The proposed patches permits Debian to include a /usr/lib/pango/1.5.0/module-files.d/ where packages can simply drop a file with a list of their modules, this will be pre-generated at build time. As a nice side effect, this makes switching to multiarch even easier as one only has to switch --libdir at ./configure time. There is no FHS compliance issue in this scheme because the files are clearly package files which are not below /etc, and no file in /etc is overwritten anymore (actually, no file is generated in postinsts anymore).
Created attachment 72928 [details] [review] Adds LIBDIR/MODULE_VERSION/module-files.d to Pango/ModuleFiles (needs 72797) Use G_SEARCHPATH_SEPARATOR_S and g_strjoin().
no longer relevant