No subject

problem but 2 implementations of the same solution. Legally and from
DAKs point of view I believe his method is unworkable.

Javier Serrano Polo <jasp00 at terra.es> writes:

> -------- Missatge reenviat --------
> De: Javier Serrano Polo <jasp00 at terra.es>
> Per a: ftpmaster at debian.org
> Cc: pkg-ia32-libs-maintainers at lists.alioth.debian.org
> Assumpte: ia32 library repository
> Data: Sat, 12 Apr 2008 13:19:37 +0200
>
> Dear FTP masters,
>
> I've been working recently in a scheme to replace the ia32-libs
> compilation with individual packages, following dependencies like their
> regular counterparts. This scheme's been initially discussed in bug
> #464796. An important conclusion we got is that these new packages need
> a new name, no matter how they're generated, and this is done with the
> ia32- prefix.
>
> I should note that this new scheme is targeted at multiarch rather than
> biarch, initially i386 to any. It's compatible with current ia32-libs,
> as it uses the multiarch directories. Maintainer collaboration is
> optional and the scheme's complementary to whatever new methods they may
> choose to generate these packages.

The ia32-libs packages does not use the multiarch scheme and hopefully
your package also do not. Instead the biarch lib / lib64 / lib32
scheme is followed (lib32 links to /emul/ia32-linux/). The multiarch
scheme (/usr/lib/i486-linux-gnu) is still not supported by binutils so
multiarch package can't be used to compile anything using ld to link.

Also different names are used (libfoo-i386, ia32-foo or lib32foo) for
the converted packages compared to what multiarch will use (libfoo).

The multiarch namespace will be kept clear so that the transition to
multiarch can be as painless as possible without creating file
conflicts. No Replaces/Conflicts/Provides entries will be
needed. That way multiarch can be added gradually in parallel to
ia32-libs packages and slowly take over for them without huge
transition deadlocks for testing and without transitional dummy
packages for versioned depends.

Please honor that in your packages also.

> Please let me know if you think this could be integrated in Debian
> somehow, what refinements would be necessary or if you need further
> details.
>
> Thanks.

MfG
        Goswin