Re: Challenge to you: Voice your concerns regarding systemd upstream
-----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-----
Reply to: