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