Bug#372508: Preparing multiarch
joss at debian.org
Tue Jun 13 18:35:06 UTC 2006
Le vendredi 09 juin 2006 à 21:02 +0200, Goswin Brederlow a écrit :
> Do users ever need to call pango-querymodules?
> This looks like it will only be called from the update-pango-modules
> script. If that is true then pango-querymodules should be moved into
> /usr/lib/pango1.0/ [becomes /usr/arch-os-gnu/lib/pango1.0] or be
> moved and renamed to /usr/lib/pango1.0/pango-querymodules.arch-os-gnu.
> If users are calling pango-querymodules then it should be replaced by
> a wrapper that takes the arch-os-gnu tripple to query as argument and
> then calls the respective pango-querymodules for that arch. Without
> argument it could go through all architectures but that could result
> in many failures when trying to load the wrong modules later.
A move to /usr/lib/pango1.0 makes sense.
> What do you want to do with the config file?
> - /etc/arch-os-gnu/pango/pango.modules (simplest, configure can handle that)
> - /etc/pango/pango.modules.arch-os-gnu
> - /etc/pango/arch-os-gnu.pango.modules
How about /var/lib/arch-os-gnu/pango1.0/pango.modules ? The file is
autogenerated and has nothing to do in /etc.
> What about /etc/defoma/config/pango.conf?
> Is that file architecture dependent? Doesn't look like we need this
> per architecture.
I don't think so.
> What to do about update-pango-modules / update-pangox-aliases?
> Those two are scripts so they don't need to be duplicated per
> architecture. But they contain the path to the plugins which differs
> between architectures under multiarch. They also have to call a
> different pango-querymodules for each architecture.
> It might be best to add a mandatory argument to the scripts for the
> arch-os-gnu tripple to be used so the script can pick the right
> pango-querymodules binary, library dir and config file.
> Alternatively the script could also be moved to /usr/lib/pango1.0 and
> then be duplicated per architecture with the library dir and config
> file hardcoded into it.
As the scripts are only useful in the pango package itself, it makes
sense to put them in /usr/lib/pango1.0 and change the call in the
> What is up with the package names?
> Normaly libfoo-common contains architecture independent files for a
> library and libfoo-bin the support binaries.
> If pango-querymodules gets moved into /usr/lib/pango1.0 it can be
> merged into libpango1.0 leaving only architecture independent files in
> libpango1.0-common. The call to update-pango-modules would then also
> need to move to libpango1.0-0 and the dependency reversed
> (libpango1.0-0 depends on libpango1.0-common). That would enable
> libpango1.0-common to be architecture all as one might expect.
Or we can simply remove libpango1.0-common.
.''`. Josselin Mouette /\./\
: :' : josselin.mouette at ens-lyon.org
`. `' joss at debian.org
`- Debian GNU/Linux -- The power of freedom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Ceci est une partie de message
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20060613/6a34be13/attachment.pgp
More information about the Pkg-gnome-maintainers