-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 09/29/2014 at 05:49 AM, Reco wrote:
> Hi. > > On Sun, Sep 28, 2014 at 04:31:01PM +0200, lee wrote: > >> Debian already lost me (after over 15 years) when they came up >> with their brokenarch and left users stranded with no possible >> fix for the things they broke. The only reason I'm here is >> because I have it running on my server, and the only reason I >> have it on my server is because it was the only distribution of >> those I tried with which I could get xen to work. I really >> didn't want to use Debian. > > What's wrong with the current multiarch implementation in your > option? I'm really curious as all multiarch complains I've seen so > far (barring actual package limits) were easily solved just by > reading an appropriate man page (or Debian wiki page). > > And, IMO, Debian's current multiarch is way more flexible than > current Fedora's one. I don't know about him, but although I'm a big supporter of multiarch in general, I do know of one major thing which broke with the transition from the old arrangement: x86 builds on amd64 hosts. Prior to multiarch, ia32-libs provided (most of) the x86 libraries, and ia32-libs-dev provided the matching header files. (Separate lib*32 packages provided other libraries, and matching -dev packages provided the matching header files for those other libraries.) With both of those together, and compiler options like 'gcc -m32', it was possible to compile code against 32-bit libraries in a 64-bit environment and then run the result in that same environment. Under multiarch, lib*:i386 packages provide the x86 libraries, and there is nothing which provides the matching header files. That sort of compilation task is no longer possible, at least not in a remotely trivial or automated fashion. Most of this isn't a problem in practice since you can build in 32-bit chroots and transfer the result to the amd64 host environment. But anything which needs to compile against both 32-bit and 64-bit libraries (such as a full-functionality Win32+Win64 Wine build) just isn't a thing anymore, AFAICT. I don't think that's sufficient justification for calling multiarch "broken"; it's just incomplete, and it has been acknowledged as such, and there has been progress (at least at the how-to-do-it-right spec level) towards addressing that deficiency. I therefore suspect that lee is referring to some other type of breakage which resulted, which I'm not aware of; it's not impossible that that breakage could, indeed, be addressed by just reading appropriate documentation. But that is one example of a complaint caused by (the in-practice Debian implementation of) multiarch which is not solved so simply, or indeed AFAICT at all without the cooperation of a multitude of library-package maintainers. - -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUKUd9AAoJEASpNY00KDJrG+AQAIeMcPNZ9zzW3mB3Nx3WY81g EDWGJ3kTuqnMQ6agA2j58fYEjvbBVQ5HniT4j/IwztbwX1bKCs2J+sSrj7E0nYZ2 BIx/1QRtknTK2Np1OTAWkszfxEW3rZTsTY6LIzmA3Q/e43AwipOk1Z1SwDEuVb6x 1x79gpnRodw2tAznQNU4Inpi1LhLXyE7rPuBSQP6mKahU677PQw/DuAmgS/ePihb DDE/hoI7/820C/DhEKzpPASFz5mscq8bjlCh6lUIXf+Ul4gVWxG0Q7oWKTCGdBmX +OQBjkCv6B+4DK3D0z8uB5x9WDj4j8i7EaXLQTVUXjZWY97g3lUbOXEgtREPHa8K JHsxegDSQmPaYCt2Sm432MjmMC8gKIzjbvUzkkTAvFJy+0GAVf/NOluTNT/yn2Hc 5lV1x+xJMwpmguLqGkpQ89r/PVgf2H5u/YHWEkQwbGc+TeVHPA1LibP0T/O4+8aa LtEWMOYLQPqkerDlkdIVpJDKo99OUIwodygqS9hKMFGJPXCGl0EX2eOsw/zi+Y0L bfHOCexe7bBQeYJv4fs4S//1dWluPjLI4QRKQ0E+FGMTIzf+lvlSEzmgE+FbR280 vtHl9RjRN/wl+DwNDaHW3GoWlQAiGf4bye6Hj+XUNfcgmpM+0TgYDk4jJ/7K7nRy P/jt12g/mqxb/K37jRjc =xYl2 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5429477d.7030...@fastmail.fm