Bug#372508: Preparing multiarch

[Goswin von Brederlow]

Loïc Minier <lool at dooz.org> writes:

>         Hi,
>
> On Wed, Jun 14, 2006, Goswin von Brederlow wrote:
>> But I think I have pango converted now. Just have to check package
>> contents tomorrow so nothing gets lost and then the big task of making
>> upgrades go smoothly. I think that will need some conffile moving or
>> deleting for the generated files.
>
>  We're in the process of replacing this part of the pango packaging
>  because of the necessity to have a working pango between unpack and
>  postinst.  THe Ubuntu packages moved the file to /var, I plan moving
>  the file too, and this is a chance to include arch information.  If you
>  have any suggestion / patch, please see:
>  <https://launchpad.net/distros/ubuntu/+source/update-manager/+bug/41297>

I will look over it this weekend. I just glanced over the patch for now.

>  I also attach today's IRC log on the subject.
>
>  The Ubuntu package also has some patches which seem closer to bi arch /
>  ia32-libs stuff which I'm attaching for you.
>
>  I would appreciate if you could process all the information and propose
>  something, otherwise I might pick a layout incompatible with multiarch,
>  and we would have to rediscuss this again in the future.
>
>
>  You mentionned that Gtk differs from Pango in that it has an ABI
>  version, I think pango has one too, so you should be able to share code
>  between these.
>
>    Bye,
> -- 
> Loïc Minier <lool at dooz.org>

> === modified file 'a/pango-1.12.3/pango/modules.c'
> --- pango-1.12.3/pango/modules.c~	2006-08-04 11:24:59.777313056 +0200
> +++ pango-1.12.3/pango/modules.c	2006-08-04 11:41:18.190571632 +0200
> @@ -24,6 +24,8 @@
>  #include <string.h>
>  #include <limits.h>
>  #include <errno.h>
> +#include <unistd.h>
> +#include <sys/utsname.h>
>  
>  #include <gmodule.h>
>  #include <glib/gstdio.h>
> @@ -489,9 +491,28 @@
>    dlloaded_modules = g_hash_table_new (g_str_hash, g_str_equal);
>    
>    if (!file_str)
> -    file_str = g_build_filename (pango_get_sysconf_subdirectory (),
> +#if defined(__linux__) && defined (__i386__)

This will only affect building 32bit code (i386)

> +    {
> +      struct utsname uts;
> +      char *sysconfdir = g_getenv("PANGO_SYSCONFDIR");
> +      if (!sysconfdir || !access(sysconfdir, R_OK|X_OK))
> +	{
> +	  uname(&uts);
> +	  if (!strcmp("x86_64", uts.machine)

while this checks the currently running kernel

> +	      && !access(SYSCONFDIR "/pango32", R_OK|X_OK))

and for the existance of the 32bit special dir, which I guess only
pango from ia32-libs on amd64 has.

> +	    sysconfdir = SYSCONFDIR "/pango32";
> +	  else
> +	    sysconfdir = "/var/lib/pango/";
> +	}
> +      file_str = g_build_filename (sysconfdir,
> +				   "pango.modules",
> +				   NULL);
> +    }
> +#else
> +    file_str = g_build_filename ("/var/lib/pango/",
>  				 "pango.modules",
>  				 NULL);
> +#endif
>  
>    files = pango_split_file_list (file_str);
>  

Two things:

1) ia64 needs the same

2) multiarch takes a simpler approach by adding arch-os-gnu where such
a destinction is needed and always adds it, no conditionals. Using
pango32 would be along the lines of biarch.

Why not always use SYSCONFDIR "/pango" DEB_HOST_GNU_TYPE? That way the
i386 package could be used as is on ia64/amd64 without having to shift
files around and special casing.

MfG
        Goswin