Stephen Gallagher wrote:
* Switch to using the Debian style of multi-arch layout, which
instead of
/usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this
would include the emergence of a de-facto standard for system layout
between the major distributions.
[snip]
== multi-arch layout ==
* Moving the locations of all of the system libraries would potentially
still break third-party applications that were compiled to expect
libraries to be in the /usr/lib[64] paths. This would be a similar problem
to the UsrMove change and would likely be solved the same way; by
maintaining symlinks in the old locations for some reasonable migration
period. Given the enormous number of packages involved and the fact that
it's not a simple directory rename, we may need to add a hack into
rpmbuild to automatically generate these symlinks in the old location.
* Switching to this layout might give a false (or possibly accurate, in
some cases) impression that one could expect Debian/Ubuntu packages to
function "out of the box" on Fedora (if using something like Alien).
Education is key here.
* This change contradicts the FHS. The FHS clearly specifies that
arch-specific libdirs should be named lib*, not lib/*. (It is funny that
Debian, which otherwise follows the FHS so strictly as to even have
refused to use the commonly-used libexec because it was not in the FHS
before 3.0, decided to violate the FHS unilaterally that way.)
* This change is backwards-incompatible. IMHO, binary compatibility with
Debian is not worth the backwards compatibility break, especially
considering that they are the ones not following the FHS.
* I do not see any practical advantage of Debian multiarch over FHS
multilib.
Kevin Kofler