On Fri, Jan 6, 2017 at 2:24 PM, Stephen Gallagher <sgall...@redhat.com> wrote: > On 01/06/2017 08:07 AM, drago01 wrote: >> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher <sgall...@redhat.com> >> wrote: >>> On 01/06/2017 01:08 AM, drago01 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. >>>> >>>> * Ship only one arch in the repositories and allow users to trivially >>>> enable the >>>> repositories for other arches through DNF if they have need. >>>> >>>> >>>> >>>> * Keep things as they are, which means things keep to "just work" (tm) >>> >>> As Bill pointed out, things "just work" for users right now and that's >>> something >>> we'd like to avoid breaking. However, that does *not* mean that it is >>> trivial to >>> do on the build side. >> >> That may be, but shifting the complexity to the user is simply not an >> option that we should seriously consider. > > You keep saying that, without describing what complexity you think is going to > hit the user.
Having to configure / setup / handle containers to run regular application is added complexity compared to simply running the applications. I think we both agree here because it is obvious ;) > I mean, if we shifted to the two-repo approach and shipped the > multi-arch repo as on-by-default, would the user experience change in any > visible way? Not to the same extent as the container solution but yes it would. Multilib is not about just having a repo with every single package as 32bti version. It is mostly libraries + a few selected ones. As others have pointed you could accidentally get mixed packages because out of sync repositories. + Minor annoyances like additional (duplicated) meta data that you have to deal with (bandwidth, time to install packages / updates). _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
