Bug#372508: Preparing multiarch

Goswin von Brederlow brederlo at informatik.uni-tuebingen.de
Wed Jun 14 10:52:57 UTC 2006


Thanks for the reply. A patch will follow soon then.

Josselin Mouette <joss at debian.org> writes:

> Le vendredi 09 juin 2006 à 21:02 +0200, Goswin Brederlow a écrit :
>> 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
> postinst.

If the scripts are only used in pango itself that makes it easy to
change the api as well. I will have a look how easy it would be to
pass the libdir as argument and keep the scripts in /usr/share. If
that has any problems I will move them in the patch.

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

The -common package has manpages and defoma stuff in it that is
unversioned. If that gets merged into the libpango1.0-0 package you
get a problem when the libpango1.0-1 gets uploaded as well as with
multiarch.

MfG
        Goswin






More information about the Pkg-gnome-maintainers mailing list