On Sun, May 12, 2013 at 8:06 AM, Matthias Klose <d...@debian.org> wrote:
> Am 12.05.2013 16:18, schrieb Daniel Schepler: > > Maybe we could have a release goal of dropping as many lib32* and lib64* > > packages as possible in favor of multi-arch. (And also as many package > > dependencies on libc6-[i386|amd64] as possible, which would in addition > > mean limiting some packages to arch:i386 if they currently provide a fake > > arch:amd64 package with an i386 binary.) > > > > Of course, to completely get rid of everything including libc6-* and > > lib32gcc1, etc., we'd need special configuration on the buildds to > continue > > building gcc with multilib support; and the GCC maintainer has expressed > > resistance to being that radical even if we could get this buildd > support. > > Well, GCC should keep building with a sane amount of effort. And that > currently > means not depending on a "foreign" architecture on the buildds. So before > this > can happen: > > - get dpkg ready to accept b-d's on foreign architectures. > > - get GCC ready to search for gcc_lib_dir for foreign multilibs. > and get this submitted upstream before getting it to the Debian > packages. > I didn't need to do anything special on this back when I did the proof of concept. All I had to do was adjust the <gcclibdir>/32/libgcc_s.so symlink created in the packaging to point to the multiarch location. > > - find a solution for multilibs which are not fully supported > architectures, > but only partial ports, or ports maintained outside the archive. > That case could continue to use multilib without creating the (admittedly minor) redundancy that multilib + multiarch creates. > > - get the buildd infrastructure ready. > > - find a solution that GCC's b-d's may not be installable anymore with > the current approach to binNMUs. > OK, that's a good point that I hadn't thought of before. So, it does make sense to keep libc6-i386 and lib32gcc1 if only for cross-architecture version skew issues. But I also think for most users it would make sense to allow for the option of satisfying gcc-multilib's dependencies using multiarch, and to make this the default option on multiarch systems. Though that would probably involve adding alternatives somewhere which might be more trouble than it's worth... > > It is wrong to drop the current multilib support before these are > implemented > and in place. > > So what do you commit to work on? > > I don't think that there are that many packages where you can or should > drop > multilib support. So it would be wrong to drop multilib support for zlib > (GCC, > gdb), ncurses, readline, expat (gdb) now. And there are not that many more > packages providing multilib support. > Umm, maybe this is a stupid question, but why would we need to support uploading packaged cross-compiled versions of gdb? As for the others you listed, I've gotten by just fine on x32 without any lib[32|64]z1 etc. packages. (Also, on a side note: do you have any idea why expat provides lib64expat1 but no lib32expat1?) -- Daniel Schepler
