Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/06/2017 08:45 AM, drago01 wrote:
> On Fri, Jan 6, 2017 at 2:24 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
>> On 01/06/2017 08:07 AM, drago01 wrote:
>>> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> 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.




Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux