-----BEGIN PGP SIGNED MESSAGE-----
____/ Homer on Friday 12 Aug 2011 07:40 : \____
> Verily I say unto thee that JeffM spake thusly:
>> Roy Schestowitz wrote:
>>> | This means that Debian users can now run the software of their
>>> | choice, in a machine and version of their choice. This is a feature
>>> | that is already supported by most open source distros
>> Say what?
>> Debian supports 11 architectures (more than anybody else).
> That's not what Multiarch is. It's support for multiple architectures on
> the /same/ system using a single library path:
> Multiarch is the term being used to refer to the capability of a system
> to install and run applications of multiple different binary targets on
> the same system. For example running a i386-linux-gnu application on an
> amd64-linux-gnu system. This example is the most common case, but many
> other working combinations are possible, such as armel and armhf.
> The Debian Multiarch proposal represents a radical rethinking of the
> filesystem hierarchy with respect to library and header paths. As such,
> it is a very disruptive change; software has long assumed that on Unix
> systems the library and include paths are sister directories at the same
> level of the hierarchy, and multiarch violates this assumption
> thoroughly. Even if all the various upstream build systems avoided
> hard-coding this assumption and were perfectly content to trust the
> system path (which today they are not), there would still be the matter
> of getting these directories on the system path to begin with - which
> means patching (or wrapping) all the various compilers in use.
> If we are going to ask compiler upstreams to accommodate this seemingly
> gratuitous difference, and ask other distributions to embrace multiarch
> as a new standard, it behooves us to make a case for why such a change
> is needed at all.
> Current practices
> The FHS and LSB have standardized the x86_64 architecture to use /lib64
> as the path for 64-bit x86 libraries, with /lib reserved for 32-bit x86
> libraries on such systems. This is in spite of the fact that for
> performance reasons, x86_64 is the preferred ABI to use on hardware that
> supports it.
> Red Hat and SuSE have adopted this standard. Debian and Ubuntu have
> declined to adopt this provision of the FHS, because the inconsistency
> introduced by special-casing of x86_64 would require deep changes to the
> packaging tools for incremental benefit.
>> and why is Debian being said to be behind?
> The author hasn't understood the purpose of Multiarch either. Debian is
> behind its /own/ schedule, not behind other distros. This is in fact a
> new paradigm being introduced by Ubuntu and Debian, because they don't
> like the existing FHS hack.
Apple might never need to embrace this because it forces people to buy its own
hardware, but Microsoft seems to be well behind in that regard.
Another example of GNU/Linux being well ahead of the curve and benefiting
~~ Best of wishes
Dr. Roy S. Schestowitz (Ph.D. Medical Biophysics), Imaging Researcher
http://Schestowitz.com | GNU/Linux administration | PGP-Key: 0x74572E8E
Editor @ http://techrights.org & Broadcaster @ http://bytesmedia.co.uk/
GPL-licensed 3-D Othello @ http://othellomaster.com
Non-profit search engine proposal @ http://iuron.com
Contact E-mail address (direct): s at schestowitz dot com
Contact Internet phone (SIP): schestowitz@xxxxxxxxx (24/7)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----