Re: Proposal: Rethink Fedora multilib support

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

 



On Thu, Jan 5, 2017 at 11:03 AM, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
> # Overview
>
> For many years, Fedora has supported multilib by carrying parallel-installable
> libraries in /usr/lib[64]. This was necessary for a very long time in order to
> support 32-bit applications running on a 64-bit deployment. However, in today's
> new container world, there is a whole new option.
>
> I'd like to propose that we consider moving away from our traditional approach
> to multilib in favor of recommending the use of a 32-bit container runtime when
> needed on a 64-bit host.
>
>
> ## Advantages
>
> * Simplification of build-tree creation. We wouldn't have to maintain the lists
> and hacks that are required to make sure that multilib packages land in the
> correct repositories.
>
> * Less duplication of content in the mirror networks.
>
> * It will be simpler to create module content without having to reimplement all
> the multilib hacks of above. This is directly relevant to the Base Runtime
> module, whose prototype is today intentionally limited to the primary
> architecture (no multilib).
>
> * Requires us to maintain and keep up-to-date the 32-bit container base images.
>
>
> ## Disadvantages
>
> * If we eliminate multilib entirely, all applications that use 32-bit libs will
> have to either install a 32-bit host OS or install into a container. This may be
> a difficult transition for some users.
>   * Mitigation: develop and maintain tools to ease this transition.
>
> * It is unlikely that any clean upgrade path would exist. (We could make it
> *technically* possible, but likely not without breaking 32-bit software not
> installed by RPM.
>
> * Requires us to maintain and keep up-to-date the 32-bit container base images.
> (Yes, this is both an advantage and disadvantage.)
>
>

I'll be totally frank and say this entire proposal is garbage. There
is not a reasonable way this proposal is workable. It breaks the world
because it expects that you can completely segregate applications,
which you can't. It also expects that applications can be
containerized, which there are lot of cases where you can't. And it
also completely annihilates upgrade paths and user expectations on
having things like Wine, Steam, and other common applications to work.

If we're considering rethinking multilib, I'd be more inclined to see
if we could have multi-platform libdirs like how Debian does (though
they call them "multi-arch" libdirs). This proposed approach is
essentially broken by design because it implies that applications
should be segregated. I fundamentally disagree with this, because
there are many legitimate reasons to be able to have programs that
work together that cross architectures/platforms.

Please don't do this.


-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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