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