Re: Challenge to you: Voice your concerns regarding systemd upstream
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 09/29/2014 at 10:49 AM, Reco wrote:
> Hi.
>
> On Mon, Sep 29, 2014 at 07:50:21AM -0400, The Wanderer wrote:
>> On 09/29/2014 at 05:49 AM, Reco wrote:
>>> 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.
>
> Header files are arch-agnostic, it's the .la files that case all
> the trouble.
I'm afraid that's not always the case. I've encountered specific cases
where the headers are different between architectures.
> Still, you're raising a valid point - compiling for several arches
> was possible before multiarch, and it's not possible now without
> chroots. I prefer chroots for this (less strange dependencies in
> the 'base' system), but YMMV.
If I'm reading you right, "strange dependencies" only matter when you're
going to install what you've compiled on a machine other than the one
where the build was done. For the use case of test-building (and
test-running, and in some cases installing and actively using) the
upstream development tree, that doesn't particularly matter; there are
exceptions, but for the most part, doing that type of build on a
different machine from where the resulting binary will be used is pretty
much unheard of.
> About the only thing that I'm missing here is why would anyone
> should compile anything on a production server, Xen's dom0
> specifically (as it seems to be the main lee's concern).
I did say that I didn't think lee was referring to this same type of
breakage. This was just an example of a "multiarch complaint" such as
you said you had not seen so far; there's nothing saying it's the only
such.
- --
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
iQIcBAEBCgAGBQJUKXq3AAoJEASpNY00KDJrsIgP/1Rw4F1yf17n04XXSKwqfphv
KMfgANZKQUD55ykm0jxYEfpXVVTaCCP1c+Y8wIrdqAwX7nIGrZX2I7jF4PmEDVG+
FQK1xvrz/uMYag0xDNUYxRmxMO7/gMQF5AXmfFbWNDdJ8/DqdCMw7ZMRi7Prt/Dc
a22gjUA6K+CLsBqj78Xm7/3qzBihQ/wIJ+kfixTC260v7OKDA/Vmd1Kg+5JeANW6
VfaZKc8M7eXwtb9KD9n+woykPRw/FqTY4YeUCYmnoPUVFPV8avOUrMV8siW/p27c
p8HOvyfRf+8lN90zBxSFupUb/6b69nLGsyslBA2pCoDhMWYlCbLch4FHxme2jQfp
lFaDKyYe5o8KHDSaGRMT6ar/y/LFEDAq0Cmd+kqWQT/9dOuQTEH7WT5d5x0EcfgS
EyPLC2JSkRK1PA8CR3m4woyvac34B66zjU3lBQWx7mNHjOC08l1HVhERmjT+r+Ws
sd5crbxWLIe7tTOXtRVhURhJpfZTZYdS7PM4nzAeAKNAgtNVmWzUA2MrzybeY7qB
gJJtOxiOKlX93aGCqymHh9744+XMmiKX2h3YqM6b7Bl/YHGZA71pBCsrAs+uzt5G
TJSodZzThnFXtZSzqIUkitWmckSV4OSM6xE8X5SGPl/V1Lc/+8aTWznVcXT7h1hr
odNsAzlCKqUCUT4QOx5o
=ISaH
-----END PGP SIGNATURE-----
Reply to: