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

On Tue, Jan 17, 2017 at 12:31:05PM -0500, Carlos O'Donell wrote: > On 01/09/2017 08:18 PM, Richard W.M. Jones wrote: > > On Mon, Jan 09, 2017 at 09:20:20AM +0100, Jakub Jelinek wrote: > >> On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote: > >>> On Fri, Jan 06, 2017 at 02:47:35AM

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

On 01/09/2017 08:18 PM, Richard W.M. Jones wrote: > On Mon, Jan 09, 2017 at 09:20:20AM +0100, Jakub Jelinek wrote: >> On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote: >>> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: On Thursday, January 5, 2017 5:08:16 PM

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

> On Thu, Jan 12, 2017 at 6:11 PM, Kevin Kofler wrote: > > The sysroot approach could still work in an "FHS-compatible" way by > symlinking everything back. FHS permits symlinks to represent a > traditional tree in non-traditional structures. Yeah, we have a symbolic

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

On Thu, Jan 12, 2017 at 6:11 PM, Kevin Kofler wrote: > Saleem Abdulrasool wrote: >> First, we accepted the /usr-merge (for simplicity and since most Linux >> distributions were doing so) -- not doing so would require two parallel >> trees, but would not prohibit the same

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

Saleem Abdulrasool wrote: > First, we accepted the /usr-merge (for simplicity and since most Linux > distributions were doing so) -- not doing so would require two parallel > trees, but would not prohibit the same approach. The next thing was to > introduce a "namespace" within the filesystem

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

On 01/12/2017 06:49 AM, Neal Gompa wrote: On Thu, Jan 12, 2017 at 9:26 AM, Brendan Conoboy wrote: On 01/11/2017 08:23 PM, Kevin Kofler wrote: you must absolutely split the binaries (which would conflict with the native binaries) and the libraries (which you need to do your

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

Hello again, As a quick follow up, since one of the points that was originally brought up with the original suggestion: the changes required to GCC to support this cross-compilation model is minimally invasive. You can find the patch for this at [1]. It enables the cross-compilation model on

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

Hi, I think that an alternative approach that should be given some consideration is what I came up with for Exherbo. The differences from FHS are pretty small, and fits very easily into autotools and CMake based packages as well. There is the original motivational write up for this at:

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

On Thu, Jan 12, 2017 at 05:28:47PM +0100, Kevin Kofler wrote: > > Hey, I can agree to that. Can you agree that /usr/bin could then be a > > symlink or linkfarm to /usr/target/usr/bin? > > No. It does not make sense to put the native architecture into a sysroot, > that would be a violation of

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

Brendan Conoboy wrote: > Hey, I can agree to that. Can you agree that /usr/bin could then be a > symlink or linkfarm to /usr/target/usr/bin? No. It does not make sense to put the native architecture into a sysroot, that would be a violation of the FHS. Sysroots are only for the special use

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

On Thu, Jan 12, 2017 at 9:26 AM, Brendan Conoboy wrote: > On 01/11/2017 08:23 PM, Kevin Kofler wrote: >> >> you must absolutely split the binaries (which would conflict with the >> native >> binaries) and the libraries (which you need to do your cross-compilation >> or >> to run

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

On 01/11/2017 08:23 PM, Kevin Kofler wrote: you must absolutely split the binaries (which would conflict with the native binaries) and the libraries (which you need to do your cross-compilation or to run your non-native binaries) into separate subpackages wherever packages currently ship both,

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

On Thursday, 12 January 2017 05:23:52 IST Kevin Kofler wrote: > FHS multilib is designed only for binaries that can be natively executed, > where there is a clear, fixed preference on one architecture over another. > (If you can run both i686 and x86_64 binaries, you automatically want the >

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

Neal Gompa wrote: > It's not true that we need to change anything (as Kevin Kofler > suggested earlier in the thread) for this to be useful. There is no > policy change required for this to be an improvement over the > situation today. This is wrong, because, as you wrote: > Binaries are not

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

On 01/10/2017 01:36 AM, Florian Weimer wrote: On 01/09/2017 03:37 PM, Dennis Gilmore wrote: the only reason that aarch64 used /usr/lib64 was so it looked more like x86_64 from a user perspective, there is 64 bit arches like alpha that use /usr/lib for their libraries. We'll see soon what

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

On 01/10/2017 07:49 AM, Langdon White wrote: [snip] Exactly, yes, a huge *potential* problem. However, it is fixable with policy and changeable by exception. Just because we can have 40 versions of one thing doesn't mean Fedora will allow that. However, if there is a genuinely good reason and we

Re: Why Modularity Matters to Fedora [was Re: Proposal: Rethink Fedora multilib support (Take Two!)]

On 01/10/2017 11:49 AM, Matthew Miller wrote: On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote: Apache httpd and KDE are very interesting examples. Both KDE and Apache httpd integrate with Subversion, on two levels: KDE has Subversion client support, Apache httpd has server

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

On Tue, Jan 10, 2017 at 8:20 AM, Ian Malone wrote: > On 10 January 2017 at 10:08, Florian Weimer wrote: > > On 01/08/2017 01:52 AM, Kevin Kofler wrote: > >> > >> Brendan Conoboy wrote: > >>> > >>> Enhancing interoperability increases the reach of Fedora

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

On 10 January 2017 at 10:08, Florian Weimer wrote: > On 01/08/2017 01:52 AM, Kevin Kofler wrote: >> >> Brendan Conoboy wrote: >>> >>> Enhancing interoperability increases the reach of Fedora and doesn't >>> require a bit of compromise on the the Freedom principle. >> >> >>

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

On Mon, Jan 09, 2017 at 06:06:24PM -0500, langdon wrote: > I also am not sure I am comfortable with the move toward exposing > proprietary software that we have been considering/implementing. > However, I do think there is some benefit to being able to show > firefox next to chrome when someone

Re: Why Modularity Matters to Fedora [was Re: Proposal: Rethink Fedora multilib support (Take Two!)]

On Tue, Jan 10, 2017 at 11:49 AM, Matthew Miller wrote: > > On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote: > > Apache httpd and KDE are very interesting examples. Both KDE and > > Apache httpd integrate with Subversion, on two levels: KDE has > >

Why Modularity Matters to Fedora [was Re: Proposal: Rethink Fedora multilib support (Take Two!)]

On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote: > Apache httpd and KDE are very interesting examples. Both KDE and > Apache httpd integrate with Subversion, on two levels: KDE has > Subversion client support, Apache httpd has server support. And > Subversion is implemented using

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

On 01/10/2017 12:06 AM, langdon wrote: Now, there are some use cases where the interop of the components is very important and a distribution enables this because all the things are tightly integrated. However, there is no particularly good reason for httpd and kde to be tightly integrated. Why

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

On 01/08/2017 01:52 AM, Kevin Kofler wrote: Brendan Conoboy wrote: Enhancing interoperability increases the reach of Fedora and doesn't require a bit of compromise on the the Freedom principle. Splitting a single well-integrated distribution (where all the pieces are known to work well

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

On 01/09/2017 03:37 PM, Dennis Gilmore wrote: the only reason that aarch64 used /usr/lib64 was so it looked more like x86_64 from a user perspective, there is 64 bit arches like alpha that use /usr/lib for their libraries. We'll see soon what the non-multiarch layout will be for aarch64 (but

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

On Mon, Jan 09, 2017 at 07:58:18AM -0500, Neal Gompa wrote: > The complexity of describing what they contain has also led to groups > within Fedora retroactively just gutting multi-lib support, so for > example, it's not easy to run ARMv7 binaries on an AArch64 system like > it is for i686

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

On Mon, Jan 09, 2017 at 09:20:20AM +0100, Jakub Jelinek wrote: > On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote: > > On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: > > > On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote: > > > > Two suggestions

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

On 01/09/2017 10:56 AM, Matthew Miller wrote: On Sat, Jan 07, 2017 at 03:47:56AM +0100, Kevin Kofler wrote: I don't buy this sort of alarmist bulldung that keeps being claimed with no evidence whatsoever to justify radical changes to what Fedora is all about, such as: * promoting proprietary

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

On Sat, Jan 07, 2017 at 03:47:56AM +0100, Kevin Kofler wrote: > I don't buy this sort of alarmist bulldung that keeps being claimed with no > evidence whatsoever to justify radical changes to what Fedora is all about, > such as: > * promoting proprietary drivers (making them easier to use,

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

On Mon, 2017-01-09 at 07:58 -0500, Neal Gompa wrote: > On Mon, Jan 9, 2017 at 3:20 AM, Jakub Jelinek > wrote: > > On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote: > > > On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: > > > > On Thursday, January

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

On Mon, Jan 9, 2017 at 3:20 AM, Jakub Jelinek wrote: > On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote: >> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: >> > On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote: >> > > Two

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

On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote: > On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: > > On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote: > > > Two suggestions were raised as alternatives to the container approach: > > > > > > *

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

On Sat, Jan 7, 2017 at 7:52 PM, Kevin Kofler wrote: > Brendan Conoboy wrote: >> Enhancing interoperability increases the reach of Fedora and doesn't >> require a bit of compromise on the the Freedom principle. > > Splitting a single well-integrated distribution (where all

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

On Sat, Jan 7, 2017 at 3:16 PM Richard W.M. Jones wrote: > Partly because there exist more than 2 architectures (think: > RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various > CPU features like SSE or AVX compiled in and out). Partly because > there will be

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

Brendan Conoboy wrote: > Enhancing interoperability increases the reach of Fedora and doesn't > require a bit of compromise on the the Freedom principle. Splitting a single well-integrated distribution (where all the pieces are known to work well together) into a bunch of loosely-coupled

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

Oron Peled wrote: > On Friday, 6 January 2017 19:02:16 IST Kevin Kofler wrote: >> The right way to do cross toolchains is to cross-build sysrooted packages >> from source in dedicated cross packages, which is how the Fedora cross >> toolchains work. Mixing binaries for completely different

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

On Friday, 6 January 2017 19:02:16 IST Kevin Kofler wrote: > The right way to do cross toolchains is to cross-build sysrooted packages > from source in dedicated cross packages, which is how the Fedora cross > toolchains work. Mixing binaries for completely different machines in the > same

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

On 01/06/2017 06:47 PM, Kevin Kofler wrote: I think that by destroying what Fedora is all about, we will become a footnote in history. On the other hand, sticking to our principles (Freedom) and to our technical strengths (an integrated distribution of integrated packages) will keep us relevant

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

On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote: > 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 > >

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

Matthew Miller wrote: > But if that's *all* we do, we're going to be a footnote in history. I don't buy this sort of alarmist bulldung that keeps being claimed with no evidence whatsoever to justify radical changes to what Fedora is all about, such as: * promoting proprietary drivers (making

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

On Fri, Jan 06, 2017 at 07:14:58PM +0100, Kevin Kofler wrote: > > This is a good point; we're already pretty much awful on this point, > > and let's not make it worse. (On the other hand, modularity has the > > potential to help significantly on this point, as you should't need > > detailed

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

On 01/06/2017 08:14 AM, Neal Gompa wrote: [snip] Much of what I would have said has been said by Oron (some of this I've said in earlier parts of this thread, as well). But the bigger thing is that it makes it much easier to bootstrap new architectures for Fedora, too, as we can start from

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

Matthew Miller wrote: > This is a good point; we're already pretty much awful on this point, > and let's not make it worse. (On the other hand, modularity has the > potential to help significantly on this point, as you should't need > detailed metadata about what's _inside_ a module at runtime in

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

Stephen Gallagher wrote: > 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. We're currently building out an > entirely new infrastructure to support modules;

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

Oron Peled wrote: > * With old, non-multiarch scheme: >- Library packages compiled natively on ARM would be under /usr/lib. >- But they cannot be installed on the build machine, so I can > cross-compile applications against them. >- The workaround was to unpack them, relocate the

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

Neal Gompa wrote: > I'd be happier if we just moved 32-bit libraries into /usr/lib32. That > way /usr/lib can be only noarch libs (like noarch Python things, and > stuff). Noarch stuff should NOT be in /usr/lib to begin with! True noarch stuff should be in /usr/share. Arch-colored binaries

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

On 06/01/17 13:33, Stephen Gallagher wrote: On 01/06/2017 08:04 AM, Jakub Jelinek wrote: On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote: For anyone who isn't familiar with this topic, you might find Debian's documentation useful: https://wiki.debian.org/Multiarch One could

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

On Jan 6, 2017 5:16 PM, "Neal Gompa" wrote: On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled wrote: > On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote: > >> ... > >> * I do not see any practical advantage of Debian multiarch over FHS > >> multilib. > >

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

On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled wrote: > On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote: > >> ... > >> * I do not see any practical advantage of Debian multiarch over FHS > >> multilib. > > > > Good question, multiarch is a huge win for *embedded*

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

On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote: > ... > * I do not see any practical advantage of Debian multiarch over FHS > multilib. Good question, multiarch is a huge win for *embedded* developers. Let me give real life example from my $day job: * We build stuff for arm and

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

On Fri, Jan 06, 2017 at 02:45:15PM +0100, drago01 wrote: > because out of sync repositories. + Minor annoyances like additional > (duplicated) meta data that you have to deal with (bandwidth, time to > install packages / updates). This is a good point; we're already pretty much awful on this

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

On 01/06/2017 08:45 AM, drago01 wrote: > On Fri, Jan 6, 2017 at 2:24 PM, Stephen Gallagher wrote: >> On 01/06/2017 08:07 AM, drago01 wrote: >>> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher >>> wrote: On 01/06/2017 01:08 AM, drago01 wrote:

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

On Fri, Jan 6, 2017 at 2:24 PM, Stephen Gallagher wrote: > On 01/06/2017 08:07 AM, drago01 wrote: >> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher >> wrote: >>> On 01/06/2017 01:08 AM, drago01 wrote: Two suggestions were raised as

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

On 01/06/2017 08:04 AM, Jakub Jelinek wrote: > On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote: >> On 01/05/2017 02:08 PM, Stephen Gallagher wrote: >> [snip] >>> == multi-arch layout == >>> * Moving the locations of all of the system libraries would potentially >>> still >>> break

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

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

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

On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher 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 >>

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

On Fri, Jan 6, 2017 at 8:04 AM, Jakub Jelinek wrote: > On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote: >> On 01/05/2017 02:08 PM, Stephen Gallagher wrote: >> [snip] >> > == multi-arch layout == >> > * Moving the locations of all of the system libraries would

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

On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote: > On 01/05/2017 02:08 PM, Stephen Gallagher wrote: > [snip] > > == multi-arch layout == > > * Moving the locations of all of the system libraries would potentially > > still > > break third-party applications that were compiled to

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

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 >

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

On 01/05/2017 10:35 PM, Bill Nottingham wrote: > Stephen Gallagher (sgall...@redhat.com) said: >> The main reason for this is trying to simplify the module-building process. >> We >> really don't want to attempt to build both arches within the same buildroot >> for >> most of the reasons we've

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

On Thursday, January 5, 2017, Stephen Gallagher wrote: > On 01/05/2017 11:03 AM, Stephen Gallagher 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

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

Stephen Gallagher (sgall...@redhat.com) said: > The main reason for this is trying to simplify the module-building process. We > really don't want to attempt to build both arches within the same buildroot > for > most of the reasons we've established in this extended conversation. My first >

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

On 01/05/2017 08:47 PM, Pavel Raiskup wrote: >> * 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

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

On 01/05/2017 07:20 PM, Josh Boyer wrote: >> * 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 >>

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

Stephen Gallagher wrote: > * 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. [snip] > ==

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

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

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

On Thu, Jan 5, 2017 at 7:20 PM, Josh Boyer wrote: > On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher wrote: >> On 01/05/2017 11:03 AM, Stephen Gallagher wrote: >>> # Overview >>> >>> For many years, Fedora has supported multilib by carrying >>>

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

On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher wrote: > On 01/05/2017 11:03 AM, Stephen Gallagher 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

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

On Thu, Jan 5, 2017 at 6:08 PM, Brendan Conoboy wrote: > On 01/05/2017 02:08 PM, Stephen Gallagher wrote: > [snip] >> >> == multi-arch layout == >> * Moving the locations of all of the system libraries would potentially >> still >> break third-party applications that were

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

On 01/05/2017 02:08 PM, Stephen Gallagher wrote: [snip] == 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

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

On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher wrote: > On 01/05/2017 11:03 AM, Stephen Gallagher 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

Proposal: Rethink Fedora multilib support (Take Two!)

On 01/05/2017 11:03 AM, Stephen Gallagher 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,