From mpeters at mac.com Sun Dec 11 12:26:35 2005 From: mpeters at mac.com (Michael Peters) Date: Sun, 11 Dec 2005 04:26:35 -0800 Subject: [Fedora-packaging] pango modules packaging question In-Reply-To: <13802422.1134296129229.JavaMail.daviddivine@mac.com> References: <13802422.1134296129229.JavaMail.daviddivine@mac.com> Message-ID: <11211396.1134303995294.JavaMail.mpeters@mac.com> I'm working on a spec file for a package that includes a library, and a couple pango modules that use the library. The pango modules are not part of the library proper, different code base - configured and built separately from the library. However, the module source is in same tarball as library - so building them as separate src.rpm's seems wrong. Thus I'm building them in the same src.rpm 1) Packaging the pango modules I'm 99% I'm correct on this - since these are modules to add functionallity to pango, it would be be best in this case to use: %package -n pango-%{name} in tradition of addons bearing the name of what they add function to. 2) pango-querymodules This is where I have an issue and am personally stumped. I can't seem to find a _safe_ way to register the modules in /etc/pango/$host/pango.modules according to the documentation, pango-querymodules uses the Pango module path. This is set by /etc/pango/pangorc, ~/.pangorc, and the file specified in the environment variable PANGO_RC_FILE there is not a pangorc file in Fedora, creating/modifying a ~/.pangorc file for the root user in an rpm scriptlet would be completely wrong. I could just specify the modules to pango-querymodules and >> them to the pango.modules file, but that would be undone the next time pango-querymodules > pango.modules is run. The modules are suppose to be AFTER the base pango modules in the Pango module path when pango-querymodules is run, so just dumping them in the same directory as the other pango modules might not produce the desired effect. What is the proper way to add a path via rpm to the Pango module path so that if/when pango-querymodules is run in future, the modules are queried properly? For reference - what I'm working on packaging (at the request of upstream maintainer) is the svn version of silgraphite and its pango wrapper. http://sourceforge.net/projects/silgraphite/ This is (I believe) the last thing I need to get squared to have a proper spec file. Thanks for any suggestions, especially ones that work. From mpeters at mac.com Sat Dec 17 13:39:36 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 17 Dec 2005 05:39:36 -0800 Subject: [Fedora-packaging] pango modules packaging question In-Reply-To: <11211396.1134303995294.JavaMail.mpeters@mac.com> References: <13802422.1134296129229.JavaMail.daviddivine@mac.com> <11211396.1134303995294.JavaMail.mpeters@mac.com> Message-ID: <1134826777.10233.58.camel@locolhost.localdomain> I think I've found a workable solution - at least for the time being. Unfortunately, they need to fix their code - update to rawhide g++ found some problems (which I've reported) so it doesn't build at the moment. At any rate - I would really appreciate feedback on my solution if anyone is so inclined. http://mpeters.us/silgraphite/ http://mpeters.us/silgraphite/silgraphite.spec http://mpeters.us/silgraphite/pango-silgraphite-README.fedora The solution I came up with is to install a /usr/share/pango-silgraphite directory. In that directory - a pangorc or pangorc64 file (so that both versions could be installed) in the %post scriptlet - it checks to see if an /etc/pangorc file with the correct information exists (if it does, user put it there - I don't). If correct info not there - it sets the PANGO_RC_FILE to what it installed in /usr/share/pango-silgraphite/ before running pango-querymodules thus creating an appropriate pango.modules file. This _will_ be undone by any update to pango since it will run pango-querymodules without any conf file thus using the default module path that only includes the core pango modules. For that reason - I've created a README.fedora file that tells 32-bit users how to copy the pangorc file to /etc/pango/ (which would be respected by pango-querymodules when pango is updated) 64-bit users can't do that because it would cause problems if they have both 32 and 64 bit pango. So instructions are there for 64-bit users telling them how to manually recover from a pango update wiping it. It's the best I could come up with. Proper solution would involve upstream making their pango modules less dependent upon order of pango modules in pango.modules - so that they could just be put in same directory as core pango modules. At some point hopefully that will happen. A better but not as good solution would be a fix of the core pango packages so that 32 and 64 don't both want to use the same config file it it exists. But Owen Taylor said he'd rather not go that direction at this point, but that bug http://bugzilla.gnome.org/show_bug.cgi?id=129540 being fixed is better than messing with existing pango packages. So I think what I came up with - while less ideal than above two solutions - is the best way to do it. Comments (including better way) would be appreciated. From tcallawa at redhat.com Sat Dec 17 15:04:52 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 17 Dec 2005 09:04:52 -0600 Subject: [Fedora-packaging] pango modules packaging question In-Reply-To: <1134826777.10233.58.camel@locolhost.localdomain> References: <13802422.1134296129229.JavaMail.daviddivine@mac.com> <11211396.1134303995294.JavaMail.mpeters@mac.com> <1134826777.10233.58.camel@locolhost.localdomain> Message-ID: <1134831892.30689.122.camel@localhost.localdomain> On Sat, 2005-12-17 at 05:39 -0800, Michael A. Peters wrote: > So I think what I came up with - while less ideal than above two > solutions - is the best way to do it. Comments (including better way) > would be appreciated. Looks reasonably sane to me. Again, I defer to Owen on pango issues. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my!