On 01/06/2017 08:45 AM, drago01 wrote: > 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 ;) >
Reread this thread, please. This is the suggested non-container approach to solve the problem. >> 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). By "others", I'll note you are referring to me :) Yes, but those are solvable problems. I'm thinking at this point that solving those on the server-side might be a better (and more maintainable, long-term) strategy than the hacks we have today.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
