On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
Two suggestions were raised as alternatives to the container
approach:
* 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.
Isn't this just result of good marketing of "multi-arch" distros? Because
I fail to see where that approach is superior compared to what we have.
* Ship only one arch in the repositories and allow users to
trivially
enable the repositories for other arches through DNF if they have need.
Hms, that's promising. I don't see any obvious issue here, only that
there might be packages that are "multilib clean" (not intentionally) and
thus technically parallel-installable, but we never want to have them
parallel installed.
How dnf behaves now if we enable both i866 and x86_64 repos?
Pavel
Those two suggestions are not (to my mind) incompatible with one
another and
their combination may indeed prove to be a superior solution to the one I
initially came up with and suggested.
I feel it necessary to point out some of the (surmountable) issues that such a
transition would face.
== 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.
== Separated Repositories ==
This one is actually a lot harder than it might appear at first look, mostly due
to the way our packaging dependencies are written. In many (most?) cases of
arch-ful packages, their dependencies are likely to be specified without the
%{?_isa} suffix. As a result, if we were to just blindly add the i686 repository
to a running x86_64 system, even at lower priority, there would be times when an
update would attempt to pull in the wrong architecture's package (consider
situations where the i686 mirror the user is connected to may have synced
already, but their x86_64 mirror has not). The user would inadvertently pull in
the wrong version of a dependency and their application or service might fail to
start or function unexpectedly.
So if we were to go this route, it would mean a great deal of work fixing up
hundreds (if not thousands) of spec files to add explicit architecture
dependencies, or else new functionality in DNF/libsolv to ensure that
architectures don't change in a transaction. Or, ideally, both.
I think there is a lot of potential with these ideas (and they're compatible
with our plans for modularity as well). Would people be willing to participate
in such a task if we were to undertake it?
Similarly, I'm sure there are other "gotchas" hidden here that I
didn't
immediately come up with. What other issues am I missing? I assume we made the
decision to do /usr/lib[64] in the first place for good reasons; What were they,
and are they still valid?