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

2017-01-24 Thread Richard W.M. Jones
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!)

2017-01-17 Thread Carlos O'Donell
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 C

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

2017-01-12 Thread Saleem Abdulrasool
> 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 link `/usr/host` which point

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

2017-01-12 Thread Neal Gompa
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 approach. The next thing

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

2017-01-12 Thread Kevin Kofler
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 layo

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

2017-01-12 Thread Brendan Conoboy
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 cross-compilation o

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

2017-01-12 Thread Saleem Abdulrasool
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!)

2017-01-12 Thread Saleem Abdulrasool
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: https

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

2017-01-12 Thread Matthew Miller
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 the

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

2017-01-12 Thread Kevin Kofler
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 case

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

2017-01-12 Thread Neal Gompa
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 your non-native bi

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

2017-01-12 Thread Brendan Conoboy
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, or

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

2017-01-12 Thread Oron Peled
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 > x86

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

2017-01-11 Thread Kevin Kofler
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 dupl

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

2017-01-10 Thread Brendan Conoboy
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 the

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

2017-01-10 Thread Brendan Conoboy
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!)]

2017-01-10 Thread Florian Weimer
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 suppor

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

2017-01-10 Thread Langdon White
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 and doesn't > >>> require a bit of comprom

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

2017-01-10 Thread Ian Malone
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. >> >> >> Splitting a single well-

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

2017-01-10 Thread Matthew Miller
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 loo

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

2017-01-10 Thread Igor Gnatenko
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 > > Subversion client support, Apache

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

2017-01-10 Thread Matthew Miller
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 a

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

2017-01-10 Thread Florian Weimer
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!)

2017-01-10 Thread Florian Weimer
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 togethe

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

2017-01-10 Thread Florian Weimer
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!)

2017-01-09 Thread Richard W.M. Jones
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 binaries

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

2017-01-09 Thread Richard W.M. Jones
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!)

2017-01-09 Thread langdon
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 dri

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

2017-01-09 Thread Matthew Miller
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, adding

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

2017-01-09 Thread Dennis Gilmore
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 5, 2017 5:08:16 PM

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

2017-01-09 Thread Neal Gompa
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 suggestions were raised

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

2017-01-09 Thread Jakub Jelinek
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: > > > > > > * S

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

2017-01-08 Thread Neal Gompa
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 the pieces are > known to

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

2017-01-07 Thread M. Edward (Ed) Borasky
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 fewer differences b

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

2017-01-07 Thread Kevin Kofler
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 black-bo

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

2017-01-07 Thread Kevin Kofler
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 machine

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

2017-01-07 Thread Oron Peled
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 direc

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

2017-01-07 Thread Brendan Conoboy
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 f

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

2017-01-07 Thread Richard W.M. Jones
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 > > /us

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

2017-01-06 Thread Kevin Kofler
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 the

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

2017-01-06 Thread Matthew Miller
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 metadat

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

2017-01-06 Thread Brendan Conoboy
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 libra

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

2017-01-06 Thread Kevin Kofler
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 n

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

2017-01-06 Thread Kevin Kofler
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; we

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

2017-01-06 Thread Kevin Kofler
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!)

2017-01-06 Thread Kevin Kofler
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 should

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

2017-01-06 Thread Tom Hughes
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 t

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

2017-01-06 Thread Igor Gnatenko
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. > > > > Good question, multiarch is a huge

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

2017-01-06 Thread Neal Gompa
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* developers. > > > > Let me

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

2017-01-06 Thread Oron Peled
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 x86_

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

2017-01-06 Thread Matthew Miller
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 point

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

2017-01-06 Thread Stephen Gallagher
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: > > Two suggestions were raised as

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

2017-01-06 Thread drago01
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 alternatives to the container approach: >>

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

2017-01-06 Thread Stephen Gallagher
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!)

2017-01-06 Thread Stephen Gallagher
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 multi-arch layout, which

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

2017-01-06 Thread drago01
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 >> /usr/lib and /usr/lib64 uses

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

2017-01-06 Thread Neal Gompa
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 potentially >> > stil

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

2017-01-06 Thread Jakub Jelinek
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 ex

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

2017-01-06 Thread Stephen Gallagher
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 > incl

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

2017-01-06 Thread Stephen Gallagher
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 e

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

2017-01-05 Thread drago01
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 time in > order to >

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

2017-01-05 Thread Bill Nottingham
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 > prop

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

2017-01-05 Thread Stephen Gallagher
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!)

2017-01-05 Thread Stephen Gallagher
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 >> distrib

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

2017-01-05 Thread Kevin Kofler
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] > == multi-

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

2017-01-05 Thread Pavel Raiskup
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 woul

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

2017-01-05 Thread Neal Gompa
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 >>> parallel-installable >>> libraries in /usr/lib[64]

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

2017-01-05 Thread Josh Boyer
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 time in order >> to >

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

2017-01-05 Thread Neal Gompa
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 compiled to expect librar

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

2017-01-05 Thread Brendan Conoboy
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 t

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

2017-01-05 Thread Neal Gompa
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 time in order >> to >

Proposal: Rethink Fedora multilib support (Take Two!)

2017-01-05 Thread Stephen Gallagher
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, in