New lsbappchk package and arch strategy

[Matt Taggart <taggart@debian.org>]

Hi Debian-LSBeings,

I have just packaged and uploaded the lsbappchk tool(written by the 
upstream LSB Workgroup). Hopefully it will get approved by the archive 
admins and hit unstable in the next couple days.

There is an issue that I want to bring up here because we need to make some 
decisions about Debian's lsb support strategy. The new lsbappchk package 
will FTBFS on several architectures due to the following code in 
src/tests/elfchk/proginterp.c,

-----------------------------------------------------------------------
char *ProgInterp =
#if defined(__i386__)
        "/lib/ld-lsb.so.1";
#endif
#if __powerpc__ && !__powerpc64__
        "/lib/ld-lsb-ppc32.so.1";
#endif
#if __powerpc64__
        "/lib64/ld-lsb-ppc64.so.1";
#endif
#if defined(__ia64__)
        "/lib/ld-lsb-ia64.so.1";
#endif
#if __s390__ && !__s390x__
        "/lib/ld-lsb-s390.so.1";
#endif
#if __s390x__
        "/lib64/ld-lsb-s390x.so.1";
#endif
#if __x86_64__
        "/lib64/ld-lsb-x86_64.so.1";
#endif
-----------------------------------------------------------------------

We could add additional if statements or maybe even try and create a 
generic one but they're not going to work until those files exist. Right 
now those files are created by the Debian lsb package(as symlinks to the 
real linkers).

So the question we need to answer is: Should we,

a.) only support the architectures that upstream claims to support
  * all lsb packages should list only those archs in Architecture:
  * the lsb package should only create symlinks for only those archs
  * the above lsbappchk file above, and other such cases, should
     support only those archs
b.) support all debian architectures
  * the lsb packages should be Architecture: any or all
  * the lsb package should create symlinks for all archs(this might
     mean making decisions that upstream normally makes, where the
     symlink would point and the official arch name)
  * other lsb packages would need Debian specific changes to add
     support for architectures that upstream does not (yet) support
c.) some combination

I'm leaning towards option b, but I haven't thought through all the 
implications.

Comments and recommendations?

Thanks,

-- 
Matt Taggart
taggart@debian.org