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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
