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 +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 > > /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. > > Isn't this just result of good marketing of "multi-arch" distros? > Because > I fail to see where that approach is superior compared to what we have. > >>> > >>> Partly because there exist more than 2 architectures (think: > >>> RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various > >> > >> Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using suffixes > >> for */lib is able to deal with more than 2 multilibs, e.g. MIPS has > >> 3 I think. And ISA flags you meantion (SSE, AVX) should not be separate > >> multilib, those are just optimizations you can do in the same multilib, > >> that > >> can and should be resolved either completely inside of libraries that want > >> to have optimized parts (using IFUNC, target_clones, ...) > > > > I should note that RV64G vs RV64GC (compressed) is not something that > > could be handled by ifuncs. It's a deep change that affects all the > > generated code. I'm hoping that every other RISC-V extension _can_ be > > handled only using ifuncs/target_clones etc. > > Could you clarify why IFUNC doesn't work? RISC-V normally uses a fixed size 32 bit encoding for every instruction*. The compressed extension (C) allows you to substitute 16 bit encodings for a limited subset of instructions. You would do this throughout all of your binaries and libraries (kernel too), so ifunc just isn't applicable. It's also beneficial to do this because it will reduce i-cache pressure and code size generally. At present it's unclear if real hardware will use RV64G or RV64GC or there will be a mixture of the two. If all real hardware uses RV64GC then IMHO we should just use compressed everywhere as part of our base requirements and the problem goes away. If RV64GC is uncommon, we'd ignore it and again it's not a problem. The problem arises if there is hardware falling in both camps and we want to support all of it optimally, in which case we'd probably need two builds of Fedora or some sort of advanced multiarch support. Rich. * Except when it doesn't -- some extensions will be allowed to use two or more adjacent 32 bit words to encode a single instruction, but we can ignore those here. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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 > would > include the emergence of a de-facto standard for system layout between > the major > distributions. Isn't this just result of good marketing of "multi-arch" distros? Because I fail to see where that approach is superior compared to what we have. >>> >>> Partly because there exist more than 2 architectures (think: >>> RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various >> >> Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using suffixes >> for */lib is able to deal with more than 2 multilibs, e.g. MIPS has >> 3 I think. And ISA flags you meantion (SSE, AVX) should not be separate >> multilib, those are just optimizations you can do in the same multilib, that >> can and should be resolved either completely inside of libraries that want >> to have optimized parts (using IFUNC, target_clones, ...) > > I should note that RV64G vs RV64GC (compressed) is not something that > could be handled by ifuncs. It's a deep change that affects all the > generated code. I'm hoping that every other RISC-V extension _can_ be > handled only using ifuncs/target_clones etc. Could you clarify why IFUNC doesn't work? -- Cheers, Carlos. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 link `/usr/host` which points to the current target (e.g. `/usr/host` -> `/usr/x86_64-unknown-linux-gnu`), and then `/usr/include` would become a symbolic link to `/usr/host/include`. Sorry, I should have made that explicit. --- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 approach. The next thing was to >> introduce a "namespace" within the filesystem layout. The root became >> `/usr/`. > > So this is the "everything is a sysroot" approach also suggested elsewhere > in this thread. > >> The differences from FHS are pretty small > > This is not true. Your directory layout is completely incompatible with the > FHS. Every single directory is not where it is supposed to be according to > the FHS. > 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. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 layout. The root became > `/usr/`. So this is the "everything is a sysroot" approach also suggested elsewhere in this thread. > The differences from FHS are pretty small This is not true. Your directory layout is completely incompatible with the FHS. Every single directory is not where it is supposed to be according to the FHS. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 cross-compilation or to run your non-native binaries) into separate subpackages wherever packages currently ship both, or modify RPM's ELF coloring heuristics to be a lot more complex and also to take the system's actual native architecture into account. 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_64 one in case of conflicts.) Debian multiarch attempts to support use cases that fail that assumption hardcoded deep into RPM and into Fedora packaging practices. While it is true that RPM does assume native across the board at the build stage, it does have some support for not assuming that at install time. There is a tiny bit of scaffolding for supporting a cross-compile/multi-arch build case in RPM, though it definitely would need work. Some time ago, I had filed a bug upstream about this[1], but depending on where we want to go with this, it might become even more important. But most of the problems are not at the RPM level, they are at Fedora's packaging level. That being said, just changing from /lib to /lib/ is somewhat of an improvement in its own right, as people who are building but not necessarily packaging can leverage libraries to run arbitrary foreign architectures. [1]: https://github.com/rpm-software-management/rpm/issues/103 Yes, multiarch requires changing things. Using platform libdirs is admittedly a half-step (as Kevin points out, fully implementing Debian-style multiarch requires a lot more splitting than what Fedora is used to, though I think this is basically second nature for the majority of RPM-based distributions). Those use cases are much better served by full GNU sysroots (/usr/target, not /usr/lib/target). Hey, I can agree to that. Can you agree that /usr/bin could then be a symlink or linkfarm to /usr/target/usr/bin? So you're instead proposing that we move fully to sysroot style for everything? Not that it's necessarily a bad thing, but we'll have to bend quite a lot of things to make that work, especially since sysroots are designed to host their own full FHS (including /etc, /var, and /share). The tricky part the comes with how do we handle maintaining a shared configuration state with multiarch configurations (i686 on x86_64, armv7hl on aarch64, riscv on riscv, etc.). Currently, we can make the assumption that directories like /etc, /var, /usr/share, etc. contain common data. But sysroots, by definition, cannot make that assumption. Not everything, just the architecture specific bits. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 x86, x86_64, PPC, Itanium, and ARM, and AArch64. Additionally, a tiny second patch [2] tweak the build system for the prefixed tools. There may be a better way for accomplishing the changes that I have performed here, but this was the cleanest way that I saw. [1] https://git.exherbo.org/arbor.git/tree/packages/sys-devel/gcc/files/gcc-6-exherbo-multiarch-paths.patch [2] https://git.exherbo.org/arbor.git/tree/packages/sys-devel/gcc/files/gcc-6-objdump-name.patch -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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: https://exherbo.org/docs/multiarch.txt To summarize the difference: 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 layout. The root became `/usr/`. A few directories were exempt from this (which is a trivial modification and could be ignored), namely /usr/share (for shared, read-only, host-agnostic data). The toolchain was changed to be prefixed (-tool) as that simplified detection and folded into the autotools system better. Because the usual prefix is `/usr/local`, and most linux distributions use `/usr` for the distribution packages, most packages are already familiar with the idea of a modified prefix. We use `/usr/` as the prefix, and always use `lib` as the library directory. At this point, all packages use the modified prefix, and are always cross-compiled. There were a few packages that behaved badly f or cross-compilation, but we have found most upstream developers accepting of patches for fixing those issues and enabling cross-compilation in the process. /usr/i686-unknown-linux-gnu/{bin,lib} /usr/x86_64-unknown-linux-gnu/{bin,lib} would allow the co-installation of 32-bit and 64-bit libraries without collision, as well as tools as desired. By having the prefix itself be modified, the debug information for the various builds also is separated, and can be co-installed without issues (/usr//lib/debug/...). One thing to note about this approach is that we replicate the header structure as well. This is because some applications have target specific headers [1]. Having multiple copies of the headers is not too expensive, and so it allows for a class of issues to be entirely side stepped. To demonstrate how well this actually fits into most of the GNU environment: this effectively resulted in changing the value being passed to `--prefix` and `--datadir` for autotools based packages. The rest was just a consequence of the setup and the cross-compilation. I think that it is useful to provide some examples of things which are enabled by such a layout as it does diverge a bit from the traditional layout which can be a contentious point. The idea allows for multiple (arbitrary) targets to be co-installed, with complete images that would permit generation of a complete image (embedded or otherwise). This is extremely helpful if you are trying to target an embedded system: you cross-compile the full image, and then copy the subtree that matters for the target (/usr/, /usr/share, /var). This also works wonderfully if you are trying to do OS development: you cross-compile and host a TFTP server which permits you to PXE boot the full image. Another tweak would be a quick symlink adjustment (/usr/host) during boot from the initramfs would permit a switch of the host ABI (for multi-ABI hosts, e.g. MIPS) given a complete installation of multiple ABIs (it should be possible to co-install the full spectrum of MIPS ABIs with this!). Im happy to answer questions that you may have about issues that we ran into during the migration or how to address any issues that may have been overlooked in our approach. I'd like to point out that although the idea and initial prototype was my work, the final implementation would not have been possible without the immense help that I received from the rest of the developers on the Exherbo project. [1] https://src.fedoraproject.org/cgit/rpms/curl.git/tree/curl.spec#n197 -- Saleem Abdulrasool compnerd (at) compnerd (dot) org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 the FHS. Sysroots are only for the special use > cases of cross-compiling or software emulation. A normal user should never > see one. "That violates the FHS" isn't a reason by itself. FHS compliance is a good goal, but maybe the FHS doesn't support our needs as currently implemented; it's not like it's carved in stone, and we can work with the Linux Foundation and other distributions to update it as necessary. See the addition of /usr/libexec in 3.0, for a practical example. Or see the changes we worked to get for clarity around /opt/. But that said: I don't you're completely right about this being forbidden by the FHS in the current incarnation. /usr/bin is given the title "Most user commands" and "This is the primary directory of executable commands on the system." Under Specific Options, the FHS says "The following files, or symbolic links to files, must be in /usr/bin, if the corresponding subsystem is installed" so symlinks are already an acceptable way to fulfill the /usr/bin requirements. Whether /usr/target/usr/bin would be acceptable for the "real" binaries is more "currently unhandled" than "forbidden". If we *were* to decide that we wanted to do it this way, we could figure something out. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 cases of cross-compiling or software emulation. A normal user should never see one. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 your non-native binaries) into separate subpackages wherever >> packages >> currently ship both, or modify RPM's ELF coloring heuristics to be a lot >> more complex and also to take the system's actual native architecture into >> account. >> >> 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_64 one in case of conflicts.) Debian multiarch attempts to support use >> cases that fail that assumption hardcoded deep into RPM and into Fedora >> packaging practices. While it is true that RPM does assume native across the board at the build stage, it does have some support for not assuming that at install time. There is a tiny bit of scaffolding for supporting a cross-compile/multi-arch build case in RPM, though it definitely would need work. Some time ago, I had filed a bug upstream about this[1], but depending on where we want to go with this, it might become even more important. But most of the problems are not at the RPM level, they are at Fedora's packaging level. That being said, just changing from /lib to /lib/ is somewhat of an improvement in its own right, as people who are building but not necessarily packaging can leverage libraries to run arbitrary foreign architectures. [1]: https://github.com/rpm-software-management/rpm/issues/103 > > > Yes, multiarch requires changing things. > Using platform libdirs is admittedly a half-step (as Kevin points out, fully implementing Debian-style multiarch requires a lot more splitting than what Fedora is used to, though I think this is basically second nature for the majority of RPM-based distributions). >> Those use cases are much better served by full GNU >> sysroots (/usr/target, not /usr/lib/target). > > > Hey, I can agree to that. Can you agree that /usr/bin could then be a > symlink or linkfarm to /usr/target/usr/bin? > So you're instead proposing that we move fully to sysroot style for everything? Not that it's necessarily a bad thing, but we'll have to bend quite a lot of things to make that work, especially since sysroots are designed to host their own full FHS (including /etc, /var, and /share). The tricky part the comes with how do we handle maintaining a shared configuration state with multiarch configurations (i686 on x86_64, armv7hl on aarch64, riscv on riscv, etc.). Currently, we can make the assumption that directories like /etc, /var, /usr/share, etc. contain common data. But sysroots, by definition, cannot make that assumption. What do we do then? -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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, or modify RPM's ELF coloring heuristics to be a lot more complex and also to take the system's actual native architecture into account. 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_64 one in case of conflicts.) Debian multiarch attempts to support use cases that fail that assumption hardcoded deep into RPM and into Fedora packaging practices. Yes, multiarch requires changing things. Those use cases are much better served by full GNU sysroots (/usr/target, not /usr/lib/target). Hey, I can agree to that. Can you agree that /usr/bin could then be a symlink or linkfarm to /usr/target/usr/bin? -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 > x86_64 one in case of conflicts.) Debian multiarch attempts to support use > cases that fail that assumption hardcoded deep into RPM and into Fedora > packaging practices. Correct. > Those use cases are much better served by full GNU sysroots (/usr/target, not > /usr/lib/target). Incorrect. As I mentioned in another thread, sysroot force you to place your libraries under the sysroot. IFF all you build are end applications, multiarch has no advantage over sysroot, BUT... If someone use sysroot and need to develop many libraries, they: * Either need to move the built libraries under the sysroot so the cross-compiler will link applications with them. * Or (as you suggested elsewhere), build them twice: first for the target device and than (with sysroot prefix) for the sysroot. Both alternatives are far worse than the nice multiarch solution which is building once and use the same binary package both on the target device and for your cross-compiling. To set the record straight: * Multiarch is paradigm shift and maybe Fedora use-cases doesn't warrant going this last-mile. * But claiming multilib is "better" than multiarch is simply wrong: multiarch solve the general case, while multilib solve only the specific case you described. (both archs are executable but one is prefered). Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 duplicated with the "Debian multiarch". So to support the one use case that multiarch supports and multilib does not: > enabling larger scale cross-compiling, and supporting loading binaries > intended for different architectures or kernels 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 modify RPM's ELF coloring heuristics to be a lot more complex and also to take the system's actual native architecture into account. 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_64 one in case of conflicts.) Debian multiarch attempts to support use cases that fail that assumption hardcoded deep into RPM and into Fedora packaging practices. Those use cases are much better served by full GNU sysroots (/usr/target, not /usr/lib/target). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
Dne 11.1.2017 v 15:25 Jonathan Wakely napsal(a): > On 07/01/17 22:53 +, Richard W.M. Jones wrote: >> On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote: >>> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: >>> > [...] >>> > ## 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. >>> > [...] >>> >>> Just wondering: Why don't we switch to a multilib/multiarch solution >>> similar to the one that Debian/Ubuntu uses? They put libs in >>> directories >>> like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu >>> (https://wiki.debian.org/Multiarch/Implementation >>> https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar >>> solution a new (de facto) standard might evolve and in the end nobody >>> would have to deal with hacks any more, because all major distros would >>> put libs in the same directories. Iirc their model has benefits for >>> cross-compilation, too. >> >> IMHO this is a much better idea. Also being closer to Debian means >> less hacking required to build GCC (or at least, it's the same hacking >> as Debian needs). > > How's that? To build GCC on Debian needs an entire new configure > option that isn't needed at all on Fedora: --enable-multiarch > > There's *more* hacking needed to build GCC on Debian. So yes, if we > copy them we'll need the same hacking as Debian needs, but that's not > less hacking than we have now. > And yet the configuration is wrong and does not support the current needs of packages on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=979403 Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, 2017-01-05 at 11:03 -0500, 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 > 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. I think this is missing the developer story. I maintain a couple of tools that currently need to handle 32-on-64-bit setups and it is a bit of a pain. So getting rid of multilib certainly would make my life easier. But some of those tools really do work better because they are 64-bit themselves but target 32-bit applications/libraries. It means they can use the full 64-bit address space while reading/writing 32-bit files/datastructures. I believe gcc and binutils/ld are in the same category. Some applications targeting 32-bit architectures are so big that you need 64-bit tools to just build them. Maybe this is a small enough development story that it doesn't really matter. But it would be good to know if developers are comfortable with a pure/native 32bit-only development toolchain. Thanks, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On 07/01/17 22:53 +, Richard W.M. Jones wrote: On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote: Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: > [...] > ## 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. > [...] Just wondering: Why don't we switch to a multilib/multiarch solution similar to the one that Debian/Ubuntu uses? They put libs in directories like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu (https://wiki.debian.org/Multiarch/Implementation https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar solution a new (de facto) standard might evolve and in the end nobody would have to deal with hacks any more, because all major distros would put libs in the same directories. Iirc their model has benefits for cross-compilation, too. IMHO this is a much better idea. Also being closer to Debian means less hacking required to build GCC (or at least, it's the same hacking as Debian needs). How's that? To build GCC on Debian needs an entire new configure option that isn't needed at all on Fedora: --enable-multiarch There's *more* hacking needed to build GCC on Debian. So yes, if we copy them we'll need the same hacking as Debian needs, but that's not less hacking than we have now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 the non-multiarch layout will be for aarch64 (but hopefully not in Fedora). Maybe something like this? /usr/lib ARMv7/armhfp binaries /usr/lib64 aarch64 64-bit binaries /usr/lib32 aarch64 in ILP32 mode (32-bit binaries) This is similar to x86_64, where the conjectured layout is: /usr/lib i386 /usr/lib64 x86_64 64-bit binaries /usr/libx32 x86_64 in ILP32 (x32, 32-bit binaries) These seem so arbitrary though- that's the appeal of a gnu triplet, even though Debian doesn't take full advantage of it. The Debian multi-arch approach has the advantage that it provides a consistent way to determine the paths, and also a systematic way to deal with file conflicts in /usr/include. Making the compiler sys-root and the runtime the same path and binaries is really nice. Pursuing this path would also mean changing dnf/rpm since today they generally don't like to install packages for non-native architectures. Stephen, are we in a seductive detail here or is this conversation applicable to your original problem? -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 can track whether that reason continues to exist over time, having the capability is a win. Is "the maintainer wants to keep maintaining it" a good enough reason? Because really when that is no longer true, that evaluation follows. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 support. And Subversion is implemented using apr (the Apache Portable Runtime library). So unless we start building Subversion twice, once for use with Apache httpd, and once for use within KDE, modules containing KDE and Apache httpd will have to agree on the same version of Subversion and the same version of apr. To cut down support overhead, we'd probably want them to use the same versions, too, but this might not always be possible (e.g., newer upstream versions may have obliterate support, which would be considered an important server-side feature, but also change the working copy format, which would not be acceptable for a stable desktop release). Thanks, Florian - that's a great example. This is an area where Fedora, in our well-meaning attempt to integrate everything, has hobbled ourselves compared to more focused distributions. A project like Solus can focus on just the desktop case and doesn't have to care about Apache as an actual server; a server-only distro can make the opposite choice. In Fedora right now, someone has to lose. Modularity gives us flexibility to make a different decision on a case-by-case basis. We can deal with this in Fedora today, and we do: mozjs17.x86_64 : JavaScript interpreter and libraries mozjs24.x86_64 : JavaScript interpreter and libraries mozjs31.x86_64 : JavaScript interpreter and libraries mozjs38.x86_64 : JavaScript interpreter and libraries mozjs45.x86_64 : JavaScript interpreter and libraries Plus the copies in Firefox and Thunderbird at the very least. The Spidermonkey Javascript implementation is probably not such a great example because there is a lot of development, but for other projects with API/ABI changes, but without so many internal changes, it would be nice to have a way to build slightly different upstream versions with the same pile of patches applied on top. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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-box > >> modules that have no idea what libraries the other modules even contain > >> actually DECREASES interoperability. > > > > > > Only if you do not rebuild each modules from scratch (with the exception > of > > the build tools themselves, but which do not end up in the module). If > you > > do rebuild the module, the build process of each component could be made > > aware what is available in the module, and integrate well with the > features > > which are available. > > > > I think this would resemble what's being done in the embedded space with > > Yocto and BitBake. > > > > Isn't that another problem? Aside from the fact you now need to > rebuild dependencies of each component every time, there's now scope > for package foo to be built with bar-2.1 while faa is built against > bar-3.0 and fuu uses its own bundled bar which was forked off bar-1.5. > While having to watch useful programs drop out (occasionally) and be > replaced (or not) because they didn't keep up with the rest of the > ecosystem is a bit annoying, the containerise-everything alternative > means reducing the incentive for programs to keep up to date, > particularly a worry for security issues, but also generally. The > externally nice and shiny container may contain code well past its > use-by-date, this is always my worry when someone suggests containers > as a way around compatibility issues, they have their uses, but they > can also amount to sweeping problems under the carpet. > > -- > imalone > http://ibmalone.blogspot.co.uk > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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 can track whether that reason continues to exist over time, having the capability is a win. langdon ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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. >> >> >> Splitting a single well-integrated distribution (where all the pieces are >> known to work well together) into a bunch of loosely-coupled black-box >> modules that have no idea what libraries the other modules even contain >> actually DECREASES interoperability. > > > Only if you do not rebuild each modules from scratch (with the exception of > the build tools themselves, but which do not end up in the module). If you > do rebuild the module, the build process of each component could be made > aware what is available in the module, and integrate well with the features > which are available. > > I think this would resemble what's being done in the embedded space with > Yocto and BitBake. > Isn't that another problem? Aside from the fact you now need to rebuild dependencies of each component every time, there's now scope for package foo to be built with bar-2.1 while faa is built against bar-3.0 and fuu uses its own bundled bar which was forked off bar-1.5. While having to watch useful programs drop out (occasionally) and be replaced (or not) because they didn't keep up with the rest of the ecosystem is a bit annoying, the containerise-everything alternative means reducing the incentive for programs to keep up to date, particularly a worry for security issues, but also generally. The externally nice and shiny container may contain code well past its use-by-date, this is always my worry when someone suggests containers as a way around compatibility issues, they have their uses, but they can also amount to sweeping problems under the carpet. -- imalone http://ibmalone.blogspot.co.uk ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 looks to install it. With > information about the differences. We have no opportunity to educate > users when they just go to google and download it directly. Again, > modularity or containers have no bearing on that discussion, they > are an implementation detail. N.B. this is referring to yet a separate thing unrelated to *either* multilib or Modularity; a proposal from Workstation to allow users to opt-in to selected third-party repositories which may contain proprietary software. It's a good conversation but *way* off the topic here. (And I know I'm encouraging the wandering by replying but I just wanted to make sure that that's clear for anyone following along or finding this later.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 > > Subversion client support, Apache httpd has server support. And > > Subversion is implemented using apr (the Apache Portable Runtime > > library). > > > > So unless we start building Subversion twice, once for use with > > Apache httpd, and once for use within KDE, modules containing KDE > > and Apache httpd will have to agree on the same version of > > Subversion and the same version of apr. To cut down support > > overhead, we'd probably want them to use the same versions, too, but > > this might not always be possible (e.g., newer upstream versions may > > have obliterate support, which would be considered an important > > server-side feature, but also change the working copy format, which > > would not be acceptable for a stable desktop release). > > Thanks, Florian - that's a great example. This is an area where Fedora, > in our well-meaning attempt to integrate everything, has hobbled > ourselves compared to more focused distributions. A project like Solus > can focus on just the desktop case and doesn't have to care about > Apache as an actual server; a server-only distro can make the opposite > choice. In Fedora right now, someone has to lose. Modularity gives us > flexibility to make a different decision on a case-by-case basis. At this point modularity doesn't help with this at all. It doesn't solve problems when you want to have library with 2 variants. > > -- > Matthew Miller > > Fedora Project Leader > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 apr (the Apache Portable Runtime > library). > > So unless we start building Subversion twice, once for use with > Apache httpd, and once for use within KDE, modules containing KDE > and Apache httpd will have to agree on the same version of > Subversion and the same version of apr. To cut down support > overhead, we'd probably want them to use the same versions, too, but > this might not always be possible (e.g., newer upstream versions may > have obliterate support, which would be considered an important > server-side feature, but also change the working copy format, which > would not be acceptable for a stable desktop release). Thanks, Florian - that's a great example. This is an area where Fedora, in our well-meaning attempt to integrate everything, has hobbled ourselves compared to more focused distributions. A project like Solus can focus on just the desktop case and doesn't have to care about Apache as an actual server; a server-only distro can make the opposite choice. In Fedora right now, someone has to lose. Modularity gives us flexibility to make a different decision on a case-by-case basis. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 can't they be using different versions of libraries assuming they are equally secure but different in feature set? 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 apr (the Apache Portable Runtime library). So unless we start building Subversion twice, once for use with Apache httpd, and once for use within KDE, modules containing KDE and Apache httpd will have to agree on the same version of Subversion and the same version of apr. To cut down support overhead, we'd probably want them to use the same versions, too, but this might not always be possible (e.g., newer upstream versions may have obliterate support, which would be considered an important server-side feature, but also change the working copy format, which would not be acceptable for a stable desktop release). Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 together) into a bunch of loosely-coupled black-box modules that have no idea what libraries the other modules even contain actually DECREASES interoperability. Only if you do not rebuild each modules from scratch (with the exception of the build tools themselves, but which do not end up in the module). If you do rebuild the module, the build process of each component could be made aware what is available in the module, and integrate well with the features which are available. I think this would resemble what's being done in the embedded space with Yocto and BitBake. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 hopefully not in Fedora). Maybe something like this? /usr/lib ARMv7/armhfp binaries /usr/lib64 aarch64 64-bit binaries /usr/lib32 aarch64 in ILP32 mode (32-bit binaries) This is similar to x86_64, where the conjectured layout is: /usr/lib i386 /usr/lib64 x86_64 64-bit binaries /usr/libx32 x86_64 in ILP32 (x32, 32-bit binaries) The Debian multi-arch approach has the advantage that it provides a consistent way to determine the paths, and also a systematic way to deal with file conflicts in /usr/include. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 binaries on x86_64. Note that some AArch64 hardware won't run ARMv7 binaries without using software emulation (qemu-system-arm). Unlike with x86 the ability to run 32 bit code is an option. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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. > > > > > > Isn't this just result of good marketing of "multi-arch" distros? Because > > > I fail to see where that approach is superior compared to what we have. > > > > Partly because there exist more than 2 architectures (think: > > RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various > > Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using suffixes > for */lib is able to deal with more than 2 multilibs, e.g. MIPS has > 3 I think. And ISA flags you meantion (SSE, AVX) should not be separate > multilib, those are just optimizations you can do in the same multilib, that > can and should be resolved either completely inside of libraries that want > to have optimized parts (using IFUNC, target_clones, ...) I should note that RV64G vs RV64GC (compressed) is not something that could be handled by ifuncs. It's a deep change that affects all the generated code. I'm hoping that every other RISC-V extension _can_ be handled only using ifuncs/target_clones etc. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 drivers (making them easier to use, adding them to GNOME Software, etc.), which contradicts our Freedom principle, * moving away from integrated packages (which are what a distribution is all about) towards modules and containers (which, incidentally, also make it easier to deliver non-free blobs), etc. re: non-free & packaging What about modularity would make this any better or worse than RPM? There are plenty of proprietary software examples, packaged properly (arguably, because it is hard to tell with no sources), delivered as RPM. The reason we don't have them in Fedora is purely *policy* and the good people enforcing that policy. A technical shift to containers or modularity would/should have no impact on that policy. 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 looks to install it. With information about the differences. We have no opportunity to educate users when they just go to google and download it directly. Again, modularity or containers have no bearing on that discussion, they are an implementation detail. re: distributions I agree that this is what a distribution *does* traditionally. However, I don't agree that the goal was a completely integrated set of things. The goal was to ensure that 1) all the things worked 2) space was minimized 3) security could be enforced easily. The goal of modularity is to lower the 1st & 2nd requirement a bit and keep the 3rd at the same level it is now. I do not believe that anyone thinks that having httpd/mod_ssl and ssh sharing the same ssl library instance is somehow "good" just in and of itself. They want to have only one ssl library for the 1,2, and 3. There may be other reasons but "that's the way we have always done it" shouldn't be one of them. 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 can't they be using different versions of libraries assuming they are equally secure but different in feature set? As a result, modules let us look at having "complete integration" at a more granular level than "fedora." This does not mean that kde and all its desktop apps might not be one module providing for the same very tight integration they have today. With modularity, httpd can be doing something different from KDE but also be tightly integrated with its own ecosystem like the various pluggable modules. Separating the libraries from binaries, having multiple arch support in a generic manner, etc all allow the *operating system* we are delivering to be more flexible in terms of the *applications* that it runs. The distribution concept might, in some ways, be lost but the goals of the distribution would be retained just leveraging different mechanisms to implement it. Langdon I don't think it's "alarmist" to note that things change, and that we need to be aware of and follow changes to remain relevant. And, there is plenty of evidence that things have, in fact, changed, and will be changing even more and more rapidly over the next few years. I encourage you to look at pretty much *any* analyst report over the last few years, or attend a big IT conference yourself and _talk to people_. But — and I don't know how I can stress this any louder — this is all *technical change*. None of it is about changing Fedora's fundamental values. Fedora is and will always be a pure free software project. That's what we are all here for. Now, I do see that many people in this larger thread care about avoiding changes that break existing proprietary software. To me, that's _caring about users_, not promoting the proprietary software; if all those users are forced elsewhere, we have no way of reaching them at all. So, yeah, let's not break Steam and Wine and whatever else, unless we have a really strong reason. But none of this has to do what you are responding to specifically, which is the Modularity effort. I can state unequivocally that "making it easier to deliver non-free blobs" isn't any part of the motivation. It is entirely about how we can better deliver the universe of free and open source software. 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) wi
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, adding them to > GNOME Software, etc.), which contradicts our Freedom principle, > * moving away from integrated packages (which are what a distribution is all > about) towards modules and containers (which, incidentally, also make it > easier to deliver non-free blobs), > etc. I don't think it's "alarmist" to note that things change, and that we need to be aware of and follow changes to remain relevant. And, there is plenty of evidence that things have, in fact, changed, and will be changing even more and more rapidly over the next few years. I encourage you to look at pretty much *any* analyst report over the last few years, or attend a big IT conference yourself and _talk to people_. But — and I don't know how I can stress this any louder — this is all *technical change*. None of it is about changing Fedora's fundamental values. Fedora is and will always be a pure free software project. That's what we are all here for. Now, I do see that many people in this larger thread care about avoiding changes that break existing proprietary software. To me, that's _caring about users_, not promoting the proprietary software; if all those users are forced elsewhere, we have no way of reaching them at all. So, yeah, let's not break Steam and Wine and whatever else, unless we have a really strong reason. But none of this has to do what you are responding to specifically, which is the Modularity effort. I can state unequivocally that "making it easier to deliver non-free blobs" isn't any part of the motivation. It is entirely about how we can better deliver the universe of free and open source software. > 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 for a long time to come. All of this stuff you are saying about "destroying what Fedora is all about" is the "alarmist nonsense" with no evidence or justification. I don't see how it's helpful whatsoever to rant about it. And we need to also remember some of the other Fedora foundations — when there is change in the open source world, we should be exploring and leading that change: Features and First. All of that together is what Fedora is all about. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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 would > > > > > include the emergence of a de-facto standard for system > > > > > layout between the major > > > > > distributions. > > > > > > > > Isn't this just result of good marketing of "multi-arch" > > > > distros? Because > > > > I fail to see where that approach is superior compared to what > > > > we have. > > > > > > Partly because there exist more than 2 architectures (think: > > > RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having > > > various > > > > Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using > > suffixes > > for */lib is able to deal with more than 2 multilibs, e.g. > > MIPS has > > 3 I think. And ISA flags you meantion (SSE, AVX) should not be > > separate > > multilib, those are just optimizations you can do in the same > > multilib, that > > can and should be resolved either completely inside of libraries > > that want > > to have optimized parts (using IFUNC, target_clones, ...) or using > > dynamic > > linker hwcaps (*/lib/sse2/, */lib/avx/ etc.). > > Unfortunately, they are only compatible in one direction. Not to > mention, from a practical perspective, ARMv8 (AArch32) and AArch64 > are > the first architectures with a solid architecture description that > everyone seems to be following. And on the other hand, you have > RISC-V, which has (IMO) too many options for how the architecture > could be defined, some of which is mutually exclusive (and thus can > cause incompatibility with itself). The way we use /usr/lib > makes it really hard to capture that effectively. > > 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 we decided when bringing up aarch64 that we would not support multilib as there was not a history of legacy software. all that would be needed is support in rpm/yum/dnf/mock part of the deciding factor was that the armv8 spec does not mandate that the soc support 32 bit at all. it is entirely optional. > it is for i686 binaries on x86_64. And of course, the same happened > to > POWER, though it has less effect since it's hard to find 32-bit > PowerPC binaries for Linux these days. We stopped supporting ppc on ppc64 when we stopped building ppc binaries. none of the support for it has been removed from anywhere. > Now, we could certainly bend things a little and do stuff like > /usr/lib-, but if we consider reworking this, and the goal is > to > fix the issues we have now, why not use a system that everyone else > already knows. > > > The Debian/Ubuntu system > > basically treats all architectures as cross-compiled, and > > duplicates all > > binaries. That doesn't make sense. Just because Debian/Ubuntu > > folks > > haven't understood or weren't able to implement the FHS multilibs > > and came > > up with something nonsensical doesn't mean everybody else should > > copy their > > mess. > > > > Binaries are not duplicated with the "Debian multiarch". The reason > I've been calling it "platform libdirs" is because that's what they > are: library directories marked for a specific platform triple. > Literally the Debian system just swaps /usr/lib for > /usr/lib/-. (Technically, there were other things involved, > but most of them do not apply to us, because RPM has a far more > powerful mechanism for managing multiple architectures than dpkg.) > 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. > > There are two reasons for this: enabling larger scale cross- > compiling, > and supporting loading binaries intended for different architectures > or kernels. Debian maintains three kernels under its project: Linux, > HURD, and kFreeBSD. While only the Linux kernel is officially > supported now (as the bringup of the others has been very hard), the > idea behind it was that programs from i386 HURD could run on x86_64 > Linux without needing to be recompiled. Likewise, Linux binaries > could > run on kFreeBSD with little trouble. And of course, with judicious > use > of user-mode emulation, you can run ARM, PowerPC, etc. Linux binaries > on x86 Linux. > > That being said, I *don't* like how
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 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. >> > >> > Isn't this just result of good marketing of "multi-arch" distros? Because >> > I fail to see where that approach is superior compared to what we have. >> >> Partly because there exist more than 2 architectures (think: >> RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various > > Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using suffixes > for */lib is able to deal with more than 2 multilibs, e.g. MIPS has > 3 I think. And ISA flags you meantion (SSE, AVX) should not be separate > multilib, those are just optimizations you can do in the same multilib, that > can and should be resolved either completely inside of libraries that want > to have optimized parts (using IFUNC, target_clones, ...) or using dynamic > linker hwcaps (*/lib/sse2/, */lib/avx/ etc.). Unfortunately, they are only compatible in one direction. Not to mention, from a practical perspective, ARMv8 (AArch32) and AArch64 are the first architectures with a solid architecture description that everyone seems to be following. And on the other hand, you have RISC-V, which has (IMO) too many options for how the architecture could be defined, some of which is mutually exclusive (and thus can cause incompatibility with itself). The way we use /usr/lib makes it really hard to capture that effectively. 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 on x86_64. And of course, the same happened to POWER, though it has less effect since it's hard to find 32-bit PowerPC binaries for Linux these days. Now, we could certainly bend things a little and do stuff like /usr/lib-, but if we consider reworking this, and the goal is to fix the issues we have now, why not use a system that everyone else already knows. > The Debian/Ubuntu system > basically treats all architectures as cross-compiled, and duplicates all > binaries. That doesn't make sense. Just because Debian/Ubuntu folks > haven't understood or weren't able to implement the FHS multilibs and came > up with something nonsensical doesn't mean everybody else should copy their > mess. > Binaries are not duplicated with the "Debian multiarch". The reason I've been calling it "platform libdirs" is because that's what they are: library directories marked for a specific platform triple. Literally the Debian system just swaps /usr/lib for /usr/lib/-. (Technically, there were other things involved, but most of them do not apply to us, because RPM has a far more powerful mechanism for managing multiple architectures than dpkg.) 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. There are two reasons for this: enabling larger scale cross-compiling, and supporting loading binaries intended for different architectures or kernels. Debian maintains three kernels under its project: Linux, HURD, and kFreeBSD. While only the Linux kernel is officially supported now (as the bringup of the others has been very hard), the idea behind it was that programs from i386 HURD could run on x86_64 Linux without needing to be recompiled. Likewise, Linux binaries could run on kFreeBSD with little trouble. And of course, with judicious use of user-mode emulation, you can run ARM, PowerPC, etc. Linux binaries on x86 Linux. That being said, I *don't* like how the platform libdirs are laid out in Debian. I would have preferred something along the lines of /usr/lib- (and leave /usr/lib for noarch libraries, like noarch Python modules, etc.), but their system exists, and I'd prefer to have greater compatibility in the Linux ecosystem than not. And if we don't move to using platform libdirs, I would *really* like to see us move 32-bit libraries out into /usr/lib32. There are distribution families that use that, and frankly, it's a good cleanup against what we have now. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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: > > > > > > * 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. > > > > Isn't this just result of good marketing of "multi-arch" distros? Because > > I fail to see where that approach is superior compared to what we have. > > Partly because there exist more than 2 architectures (think: > RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various Not all of ARM v5/6/7/8 is ABI incompatible. The FHS way of using suffixes for */lib is able to deal with more than 2 multilibs, e.g. MIPS has 3 I think. And ISA flags you meantion (SSE, AVX) should not be separate multilib, those are just optimizations you can do in the same multilib, that can and should be resolved either completely inside of libraries that want to have optimized parts (using IFUNC, target_clones, ...) or using dynamic linker hwcaps (*/lib/sse2/, */lib/avx/ etc.). The Debian/Ubuntu system basically treats all architectures as cross-compiled, and duplicates all binaries. That doesn't make sense. Just because Debian/Ubuntu folks haven't understood or weren't able to implement the FHS multilibs and came up with something nonsensical doesn't mean everybody else should copy their mess. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 the pieces are > known to work well together) into a bunch of loosely-coupled black-box > modules that have no idea what libraries the other modules even contain > actually DECREASES interoperability. > I think Brendan is talking about the platform libdirs stuff, not the insane modularity stuff. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 fewer differences between Fedora & Debian/Ubuntu which > means less friction and more chance of a random proprietary binary > simply working. > > Rich. > Random proprietary binaries do not, by definition, simply work. Proprietary binaries work *if* the proprietor has *tested* them on the specific distro and architecture. This isn't a game of chance, this is a software engineering effort, hopefully with a payoff of some kind for the proprietor and the platform vendor. -- How many people can stand on the shoulders of a giant before the giant collapses? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 black-box modules that have no idea what libraries the other modules even contain actually DECREASES interoperability. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 machines in the >> same directory tree, which will not even run on the host machine (or at >> best, very slowly through software emulation), strikes me as a horrible >> hack. > > We are not talking about running binaries, but rather linking with > libraries. With "binaries", in this context, I meant both executables and libraries. >> The de-facto standard for cross compilers (i.e., what, e.g., the GNU >> toolchain supports out of the box and defaults to) is /usr/$triplet >> (sysroot), not /usr/lib/$triplet (multiarch). And that is for a reason, >> because the former can accomodate /usr/$triplet/bin, >> /usr/$triplet/libexec etc. easily > > I've used and built such toolchains for years (thanks crosstools-ng). > They are fine if all you use them for is building "leaf" applications. > > But when your project is composed of many developed libraries -- this is > hell: > * Let's say you use your toolchain to build some libfoo shared object: >- On the target device, it may be located under /usr/lib >- But this is useless for further development, because in order to > link your applications with libfoo, it should be installed under > your $sysroot, where your toolchain will search for it > (e.g: /usr/$triplet/usr/lib) > * The common hack was to build these packages for the target >device (libraries located under /usr/lib) and than use some >"conversion" scripts that create a new package (with only libraries, >headers, pkg-config, etc.) that install them on the development >host under $sysroot. The clean approach there is to maintain 2 completely different specfiles, a $triplet-libfoo noarch package to install on the development machine, and a "native" libfoo package for $triplet (which may be natively compiled or cross-compiled) to install on the actual target machine. Converting one to the other from already-built packages is necessarily an ugly hack, I agree with you there. You really want to build the source twice from separate SRPMs. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 directory tree, which will not even run on the host machine (or at > best, very slowly through software emulation), strikes me as a horrible > hack. We are not talking about running binaries, but rather linking with libraries. > The de-facto standard for cross compilers (i.e., what, e.g., the GNU > toolchain supports out of the box and defaults to) is /usr/$triplet > (sysroot), not /usr/lib/$triplet (multiarch). And that is for a reason, > because the former can accomodate /usr/$triplet/bin, /usr/$triplet/libexec > etc. easily I've used and built such toolchains for years (thanks crosstools-ng). They are fine if all you use them for is building "leaf" applications. But when your project is composed of many developed libraries -- this is hell: * Let's say you use your toolchain to build some libfoo shared object: - On the target device, it may be located under /usr/lib - But this is useless for further development, because in order to link your applications with libfoo, it should be installed under your $sysroot, where your toolchain will search for it (e.g: /usr/$triplet/usr/lib) * The common hack was to build these packages for the target device (libraries located under /usr/lib) and than use some "conversion" scripts that create a new package (with only libraries, headers, pkg-config, etc.) that install them on the development host under $sysroot. With multiarch, libfoo will be always under /usr/lib/$triplet: * On the target device, the dynamic linker will search there before falling back to /usr/lib (for legacy libraries). * And the Debian cross-compiler will search the same paths, so you can install it on your development host (non-colliding directories). > > * With multiarch distribution (Debian/jessie in my case): > >- Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu > > *regardless* if they were built natively or cross-compiled. > >- These packages may be co-installed on my development host and be used > > by the cross compiler. > >- So I have an ARM repository, everything built (natively + cross) is > > uploaded there and I can pull library dependencies into my build > > environment. > >- And the *exact* same binary packages installed on the ARM target are > > installed and being used by the cross compilers. > > That will not work with Fedora packages, for a simple reason: Fedora > packages often contain both executables and libraries. Correct. That's why I said multiarch is far greater effort than just directory relocation and it took Debian years to reach this level. In fact, if you'll read through the Debian documentation, you'll see how many facets of the distribution it touches, from compilers and build tools, through packaging tools and package installation tools (dpkg + apt, dependency calculation etc.) > For multilib (which does not support the cross-compilation use case you > mentioned), > RPM automatically resolves the conflict between different ELF executables by > "coloring" them with their architecture and then preferring one "color" over > the other. E.g., it is clear that x86_64 binaries shall always be preferred > over i686 ones, because if you have both, you are on a 64-bit system and > will almost always want the native ones. But if RPM sees an x86 binary and > an ARM binary, it will have absolutely no way to decide which one to prefer, > so it will just raise a file conflict and you will not be able to install > the package. True. One of the changes Debian introduced to "dpkg" was the concept of secondary architectures. You can install multiarch libraries side by side, but when you install non-multiarch package (e.g: executables) it'll know to pick the primary architecture. > For Debian multiarch to work, we would also have to introduce Debian's > aggressive subpackaging of libraries, which is IMHO not an improvement. It's true that multiarch package should contain only libraries and not (arch-full) executables. It's not an improvement for end-user system, but... * For embedded -- regretfully, I can't even consider Fedora for embedded system development. * Maybe also lowering total footprint (by finer granularity) which may be boon for container people (but I haven't checked, so maybe it's not significant). Overall, going multiarch is major multi-year effort, so I agree Fedora should not jump in this direction unless it wants to cater for embedded/IoT developers. If it does, I strongly suggest learning how Debian did that, both to minimize further fragmentation as well as learning from experience of others. Thanks, -- Oron Peled
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 for a long time to come. Enhancing interoperability increases the reach of Fedora and doesn't require a bit of compromise on the the Freedom principle. I would hope our technical strengths mean we can solve the problem Stephen identified *and* maintain or enhance the multilib-using developer experience, too. If it just so happens that the solution increases the value of all Linux distributions at the same time, that's a good thing. There are more operating systems and ecosystems than the classic Linux distributions out there, so let's stay true to our principles, adapt, and grow. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 > > /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. > > Isn't this just result of good marketing of "multi-arch" distros? Because > I fail to see where that approach is superior compared to what we have. 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 between Fedora & Debian/Ubuntu which means less friction and more chance of a random proprietary binary simply working. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 05, 2017 at 01:31:19PM -0500, Daniel J Walsh wrote: > Sadly will we be hearing these same arguments 10 years from now... A 10 year horizon is also the timeframe proposed for introducing RISC-V 128 bit hardware (128 bit emulation is already available, although unless you enjoy writing machine code by hand it's not much use right now), so we'll have potentially 3 different arches to target. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Sat, Jan 7, 2017 at 5:53 PM, Richard W.M. Jones wrote: > On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote: >> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: >> > [...] >> > ## 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. >> > [...] >> >> Just wondering: Why don't we switch to a multilib/multiarch solution >> similar to the one that Debian/Ubuntu uses? They put libs in directories >> like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu >> (https://wiki.debian.org/Multiarch/Implementation >> https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar >> solution a new (de facto) standard might evolve and in the end nobody >> would have to deal with hacks any more, because all major distros would >> put libs in the same directories. Iirc their model has benefits for >> cross-compilation, too. > > IMHO this is a much better idea. Also being closer to Debian means > less hacking required to build GCC (or at least, it's the same hacking > as Debian needs). Also we can kill /usr/lib64 finally. > It improves the situation, but /usr/lib64 will be with us for a long time to come... -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote: > Lo! On 05.01.2017 17:03, Stephen Gallagher wrote: > > [...] > > ## 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. > > [...] > > Just wondering: Why don't we switch to a multilib/multiarch solution > similar to the one that Debian/Ubuntu uses? They put libs in directories > like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu > (https://wiki.debian.org/Multiarch/Implementation > https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar > solution a new (de facto) standard might evolve and in the end nobody > would have to deal with hacks any more, because all major distros would > put libs in the same directories. Iirc their model has benefits for > cross-compilation, too. IMHO this is a much better idea. Also being closer to Debian means less hacking required to build GCC (or at least, it's the same hacking as Debian needs). Also we can kill /usr/lib64 finally. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 them easier to use, adding them to GNOME Software, etc.), which contradicts our Freedom principle, * moving away from integrated packages (which are what a distribution is all about) towards modules and containers (which, incidentally, also make it easier to deliver non-free blobs), etc. The same kind of alarmist nonsense was floated back in the day by the Linspire folks towards distributions such as Fedora and Debian that refused to embrace proprietary software. Look where Fedora and Debian are now (alive and thriving) and where Linspire is now (long dead). 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 for a long time to come. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 metadata about what's _inside_ a module at runtime in normal > > circumstances.) > > At that point, we stop being a distribution and become a salad bar of > bits and pieces that may or may not work together, where both look > and feel integration and functional features will end up disabled > because they would depend on libraries from another module, and that > each contain their own redundant copies of the same libraries. I > think that is a huge step backwards, and if actually fully > implemented, will likely force me to switch to a different > distribution. Analogies are always tricky, but I think that's definitely the wrong one here. Right now what we have is a casserole, where we bake every ingredient together in the same way - in the same dish at the same temperature for the same time. With that approach, you're always going to get some ingredients which ... don't work so well. What we're exploring with Modularity is offering a menu of different dishes - and, yeah, it might be a menu where you can't order the goulash and the chocolate pudding on the same plate. This is a change, but sometimes change is okay. This change reflects a very, very real shift in IT, which containers have accelerated but which really took off over a decade ago (!) with datacenter virtualization. Not only does one not need all of the stuff running in one namespace, but it's best practice _to not to_. We spend a lot of effort optimizing for that everything-cooked-together dish, which increasingly people do not even want. As I've said since the first "Rings" proposal, if people in Fedora want to continue working on the casserole, and feel like that's an important and valuable thing, *awesome*. But if that's *all* we do, we're going to be a footnote in history. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 libraries and build up to applications relatively easily. It doesn't completely solve the issue, as there would still be some conflicts, but it makes it a lot less challenging. Enabling things like being able to do test and development with arbitrary architectures would be a huge boon, as well. [snip] Yes, beyond Oron's focus on embedded development the general reality is that it is a plain useful mechanism for using OS+architecture to do work on a different OS+architecture. We could really have used something like this for the armhfp bootstrap, or the aarch64 bootstrap, or the ppc64le bootstrap. Add in the judicious use of qemu as the suse team does and making something new is considerably less hard. X32, ilp32, mips, etc all face chicken-and-egg problems in bootstrap that this simplifies. Who knows what will be next? Multilib is likewise useful for backward compatibility across major releases and distributions. If third party software vendors only had to qualify their software on one release of one distribution with the expectation that it would run on all because the dynamic libraries were available on all it would be a real win for Linux as a whole. The fact we don't have that is part of what is driving container adoption. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 normal > circumstances.) At that point, we stop being a distribution and become a salad bar of bits and pieces that may or may not work together, where both look and feel integration and functional features will end up disabled because they would depend on libraries from another module, and that each contain their own redundant copies of the same libraries. I think that is a huge step backwards, and if actually fully implemented, will likely force me to switch to a different distribution. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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; we'd like to take a look > at what we did the first time and see if (with more experience and > hindsight) we can do a better job now, and ideally one we can share > between the two approaches. What was never discussed was whether modules are something worth rebuilding "an entirely new infrastructure" to begin with. I disagree that they are even a desirable feature to begin with, they just fragment and thus dilute the Fedora platform, and have the potential to seriously hurt integration across the distribution and increase code duplication and its resulting bloat. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 libraries, headers, > etc to the prefix expected by cross compiler (e.g: > /opt/toolchain/) and repack the result into an "all" architecture > package. 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 directory tree, which will not even run on the host machine (or at best, very slowly through software emulation), strikes me as a horrible hack. The de-facto standard for cross compilers (i.e., what, e.g., the GNU toolchain supports out of the box and defaults to) is /usr/$triplet (sysroot), not /usr/lib/$triplet (multiarch). And that is for a reason, because the former can accomodate /usr/$triplet/bin, /usr/$triplet/libexec etc. easily (or even /usr/$triplet/usr/bin etc. if desired, though in the current UsrMove world, those would likely be at most symlinks to the non-/usr variant), the latter cannot. > * With multiarch distribution (Debian/jessie in my case): >- Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu > *regardless* if they were built natively or cross-compiled. >- These packages may be co-installed on my development host and be used > by the cross compiler. >- So I have an ARM repository, everything built (natively + cross) is > uploaded there and I can pull library dependencies into my build > environment. >- And the *exact* same binary packages installed on the ARM target are > installed and being used by the cross compilers. That will not work with Fedora packages, for a simple reason: Fedora packages often contain both executables and libraries. For multilib (which does not support the cross-compilation use case you mentioned), RPM automatically resolves the conflict between different ELF executables by "coloring" them with their architecture and then preferring one "color" over the other. E.g., it is clear that x86_64 binaries shall always be preferred over i686 ones, because if you have both, you are on a 64-bit system and will almost always want the native ones. But if RPM sees an x86 binary and an ARM binary, it will have absolutely no way to decide which one to prefer, so it will just raise a file conflict and you will not be able to install the package. For Debian multiarch to work, we would also have to introduce Debian's aggressive subpackaging of libraries, which is IMHO not an improvement. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 should be in /usr/libexec. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 take it a step further and actually have target triplets the convey OS version of the libraries instead of the generic "-redhat-linux" part of the tuple. With a little rpath abuse apps compiled for F25 could find their shared libraries in an F25 specific directory and multiple versions of the same package could be installed at the same time, for different OS versions. This goes beyond Fedora, too: apps compiled for Debian could find their shared libraries in a Debian specific directory, even though it's a Fedora system that is booted. A lot of fiddly details and hand waving go here, but the end result would be really useful. Noo! Debian Multiarch is FHS incompatible, too ugly to live with and doesn't bring benefits, it is just different. Please don't introduce this into Fedora. I added it to this list because it came up several times in the earlier thread. I'm not sold on it. I'm CCing the people who suggested it directly to ask them to chime in with what advantages they feel it would provide. So to be honest I hadn't really expected Fedora to make the change but it was certainly the first thing that came to mind from the email subject. If we were starting now to support multilib then I would certainly suggest that the Debian design is the better one but whether it's enough of an improvement to merit the pain of changing is a rather different question. My reasons for thinking it's better are much the same as what other people have already said - that it treats all arches as equals and scales readily to whatever is needed rather than just bolting on a single 32/64 bit split as a kind of special case. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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. > > > > 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_64 (I ignore our legacy platforms > > like x86, ppc, whatnot...) > > > > * We cross compile most stuff (faster), but not everything is easily > > cross-compilable: > > - Notorious examples are libraries with their own code-generation tools. > > - Examples: thrift, dbus-c++ (you need to *run* built tools) > > - So we build some packages natively (either on real ARM or in chroot with > qemu-user-static). > > > > * 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 libraries, headers, etc > > to the prefix expected by cross compiler (e.g: /opt/toolchain/) and > > repack the result into an "all" architecture package. > > > > * With multiarch distribution (Debian/jessie in my case): > > - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu > > *regardless* if they were built natively or cross-compiled. > > - These packages may be co-installed on my development host and be used > > by the cross compiler. > > - So I have an ARM repository, everything built (natively + cross) is > uploaded > > there and I can pull library dependencies into my build environment. > > - And the *exact* same binary packages installed on the ARM target are > > installed and being used by the cross compilers. > > 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 libraries and build up to applications relatively easily. It doesn't completely solve the issue, as there would still be some conflicts, but it makes it a lot less challenging. Enabling things like being able to do test and development with arbitrary architectures would be a huge boon, as well. That being said, I would be in remiss to indicate that platform libdirs (what Debian calls multiarch libdirs) are able to be implemented in a backwards-compatible way. Debian was able to pull it off because they originally used /lib32 and /lib64, but migrated to /lib/i386-linux-gnu and /lib/x86_64-linux-gnu (while creating symlinks to point to them). We should be able to do the same. If we touch this thing I would like to have /usr/lib/triple. At this moment we don't have good cross-compiler support and this would help us (at least to some degree). The main break will be that /usr/lib will no longer contain archful data, and that's going to be a difference no matter how you slice it. We could elect to do /usr/lib32 and that would still be an improvement of the situation over what we have now, but it's still a break (though not necessarily one that will break third party applications). If we don't want to do full platform libdirs, I would really like us to move 32-bit libraries to /usr/lib32. It would just be much cleaner on the filesystem that way. If we do full platform libdirs, I would like us to have the symlinks for /usr/lib32 and /usr/lib64 to point to the correct places, too. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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* developers. > > > > Let me give real life example from my $day job: > > * We build stuff for arm and x86_64 (I ignore our legacy platforms > > like x86, ppc, whatnot...) > > > > * We cross compile most stuff (faster), but not everything is easily > > cross-compilable: > > - Notorious examples are libraries with their own code-generation tools. > > - Examples: thrift, dbus-c++ (you need to *run* built tools) > > - So we build some packages natively (either on real ARM or in chroot with > qemu-user-static). > > > > * 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 libraries, headers, etc > > to the prefix expected by cross compiler (e.g: /opt/toolchain/) and > > repack the result into an "all" architecture package. > > > > * With multiarch distribution (Debian/jessie in my case): > > - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu > > *regardless* if they were built natively or cross-compiled. > > - These packages may be co-installed on my development host and be used > > by the cross compiler. > > - So I have an ARM repository, everything built (natively + cross) is > uploaded > > there and I can pull library dependencies into my build environment. > > - And the *exact* same binary packages installed on the ARM target are > > installed and being used by the cross compilers. > > 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 libraries and build up to applications relatively easily. It doesn't completely solve the issue, as there would still be some conflicts, but it makes it a lot less challenging. Enabling things like being able to do test and development with arbitrary architectures would be a huge boon, as well. That being said, I would be in remiss to indicate that platform libdirs (what Debian calls multiarch libdirs) are able to be implemented in a backwards-compatible way. Debian was able to pull it off because they originally used /lib32 and /lib64, but migrated to /lib/i386-linux-gnu and /lib/x86_64-linux-gnu (while creating symlinks to point to them). We should be able to do the same. The main break will be that /usr/lib will no longer contain archful data, and that's going to be a difference no matter how you slice it. We could elect to do /usr/lib32 and that would still be an improvement of the situation over what we have now, but it's still a break (though not necessarily one that will break third party applications). If we don't want to do full platform libdirs, I would really like us to move 32-bit libraries to /usr/lib32. It would just be much cleaner on the filesystem that way. If we do full platform libdirs, I would like us to have the symlinks for /usr/lib32 and /usr/lib64 to point to the correct places, too. -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On 5 January 2017 at 19:29, Josh Boyer wrote: > On Thu, Jan 5, 2017 at 4:40 PM, Japheth Cleaver > wrote: >> On 1/5/2017 9:12 AM, Jonathan Wakely wrote: >>> >>> On 05/01/17 09:56 -0700, Chris Murphy wrote: Teamviewer comes in an i686 only package for Fedora. So is there going to be this interim approach, and then yet another change when they're expected to use FlatPak? That's a lot of changes... And are these two approaches compatible with the other platforms they target, or are they just likely to drop the one it stops working on? I can hardly imagine Teamviewer is the only 32-bit only GUI program. >>> >>> >>> There are all sorts of proprietary programs like Skype that are only >>> provided as 32-bit packages (there's a "skypeforlinux" package which >>> is 64-bit but it's an "alpha" release). >>> >>> Maybe it would work fine from inside a 32-bit container, I have no >>> idea, but we should be careful not to make it harder for normal users >>> to install and use software distributed outside Fedora. And not make >>> it harder for ISVs to provide RPMs that work on Fedora with minimal >>> effort. >> >> >> I feel like if this happens it will hasten the day when those of us >> primarily working in EL-variant land have to consider a need for a new, >> EL-forward, RPM-based open source "community" OS. > > Can you elaborate why you think that? Particularly the "EL-forward" > part. I don't understand how Stephen's line of thinking is not > EL-forward. > I think it is because EL-forward means different things to different people. 1. Developer definition. EL-Forward is looking towards how something will work in EL-next. 2. Enterprise operations. EL-Forward is looking towards how to take something in current Fedora and move it forward to the version of Enterprise you have deployed. [From a developer point of view it is moving it backwards but it is because we are driving in two different directions.] A large amount of Enterprise ops people have to work in environments with 30% of the systems being EL-5, 50% of the systems being EL-6 and 20% being EL-7. They have to both make corporate apps work with ancient code bases but also get apps that need later items to make things work. The work flow for this is 1. Find it in an 'approved' repo. [This was in the past EPEL but less so due to aging items.] 2. Take the latest Fedora rpm and recompile/mangle the bits until it works on EL5/EL6. 3. Get a bunch of tar-balls and make them work... but pay for the upgrade problems later. If they have problems in 2 or 1 they feed that back as bug reports and considered that how they pushed Fedora forward. At some point they would get to be able to install EL-8 and would have packages they knew worked in Fedora from say Fedora-30 that would work for what they needed. Why does this not look forward to them? 1) They are still primarily having to deal with 32 bit applications. 2) They are only getting to virtualize their main environments. Yes they have some systems somewhere in the giant bank IT that are containered and that admin gets trotted out at docker con as the forward way the world is working but 99% of the operations staff is having to deal with an OS which is going to be EOL in 3 months and is only now getting a budget which says they can move it to EL6. [They can't move it to EL7 because the vendor still hasn't produced a version of XYZ that 'works with systemd' (eg it relys on some initd hack that they don't know how to fix to start up).] 3) Containers don't look baked yet. People are still arguing about how to upgrade/update them.. the ones they google to see how it works of them say they are read only but have instructions of 'install an ssh and then log in and make these changes to really get it to work' etc etc. Maybe Fedora will deliver all the packages in Fedora 27 with docker formatting.. and maybe Fedora 28 will use a completely new one.. 4) The oracles they rely on to say this is how things are done in Linux haven't agreed yet. The usual rule from previous technology changes is don't bet on what the markets are using.. see what one Linus uses for N months and if he doesn't like it see what he replaces it with as that will be the way things go. [This is usually from people who were burned deploying enterprise CVS, SVN, HG, BZR solutions to have them all replaced with git in the last 5 years.. older admins have other Linus did it this way and everyone went that way too.. the fact that Linus didn't have a tantrum and replace systemd was pretty much the "ok it looks like this is the way things are going"] So if the OS they rely on to grab/build packages no longer offers a way they can consume them (it has to be in a container which you will need to run in your EL5/6 environment somehow..) then it can look like the OS is no longer wanting EL to use it. And it doesn't matter how much Red Hat says it is banking on containers.. that is something that most of these Enterprise o
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 x86_64 (I ignore our legacy platforms like x86, ppc, whatnot...) * We cross compile most stuff (faster), but not everything is easily cross-compilable: - Notorious examples are libraries with their own code-generation tools. - Examples: thrift, dbus-c++ (you need to *run* built tools) - So we build some packages natively (either on real ARM or in chroot with qemu-user-static). * 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 libraries, headers, etc to the prefix expected by cross compiler (e.g: /opt/toolchain/) and repack the result into an "all" architecture package. * With multiarch distribution (Debian/jessie in my case): - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu *regardless* if they were built natively or cross-compiled. - These packages may be co-installed on my development host and be used by the cross compiler. - So I have an ARM repository, everything built (natively + cross) is uploaded there and I can pull library dependencies into my build environment. - And the *exact* same binary packages installed on the ARM target are installed and being used by the cross compilers. This is by far better and cleaner than the multilib, but: * It is a very big change, far wider in scope than just library directories. (pkg-config, cross-compilers, dynamic linking, rpath, packaging tools, etc.) * Debian introduced it in Debian/wheezy (~2012) but the real benefits were reaped only since Debian/jessie (~2015) when many libraries were already pre-built as multiarch and Debian shipped a multiarch aware cross-compilers. * So, I'm ambivalent here -- multiarch is great, but it's a big change and I'm not sure it's worth it *for Fedora users*. * Meanwhile, I'll keep using Fedora (KDE) as my personal workstation/server OS but develop everything at $day job on Debian (KDE) and for Debian (targets). Long live Linux ;-) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron "Debugging is at least twice as hard as writing the program in the first place. So if your code is as clever as you can possibly make it, then by definition you're not smart enough to debug it." -- Brian Kernighan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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 normal circumstances.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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: > > 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
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 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 ;) > 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). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 third-party applications that were compiled to expect libraries to be >>> in >>> the /usr/lib[64] paths. This would be a similar problem to the UsrMove >>> change >>> and would likely be solved the same way; by maintaining symlinks in the old >>> locations for some reasonable migration period. Given the enormous number of >>> packages involved and the fact that it's not a simple directory rename, we >>> may >>> need to add a hack into rpmbuild to automatically generate these symlinks >>> in the >>> old location. >>> >>> * Switching to this layout might give a false (or possibly accurate, in some >>> cases) impression that one could expect Debian/Ubuntu packages to function >>> "out >>> of the box" on Fedora (if using something like Alien). Education is key >>> here. >> [snip] >> >> For anyone who isn't familiar with this topic, you might find Debian's >> documentation useful: >> >> https://wiki.debian.org/Multiarch >> >> One could take it a step further and actually have target triplets the >> convey OS version of the libraries instead of the generic "-redhat-linux" >> part of the tuple. With a little rpath abuse apps compiled for F25 could >> find their shared libraries in an F25 specific directory and multiple >> versions of the same package could be installed at the same time, for >> different OS versions. This goes beyond Fedora, too: apps compiled for >> Debian could find their shared libraries in a Debian specific directory, >> even though it's a Fedora system that is booted. A lot of fiddly details >> and hand waving go here, but the end result would be really useful. > > Noo! Debian Multiarch is FHS incompatible, too ugly to live with and > doesn't bring benefits, it is just different. > Please don't introduce this into Fedora. I added it to this list because it came up several times in the earlier thread. I'm not sold on it. I'm CCing the people who suggested it directly to ask them to chime in with what advantages they feel it would provide. As to the FHS? It's a standard in the same way that CIM is a standard: it's a great starting point and we try to stay as close as possible to it, but if it doesn't meet our needs, we'll work around it. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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. 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? signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 >> /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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On 01/06/2017 07:33 AM, Jonathan Wakely wrote: > On 05/01/17 14:42 -0500, Randy Barlow wrote: >> On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote: >>> Which definitely changes how software is built. >> >> Containers also change the way software must be written in some cases, >> since they expect there to be one main process and don't expect that >> main process to interact with other "main" processes on the system. >> There are some program architectures that aren't well suited to be run >> in containers since containers expect programs to work in specific >> ways. I don't think they are general enough to cover all use cases. >> >> I also expect that users will not appreciate being forced to use >> containers if they want to keep being able to do things they can do >> today. Offering it to them as an option rather than the only solution >> is probably a friendlier approach. > > > That would certainly be a problem if the proposal was to run each > 32-bit application in its own container environment, but I think the > suggestion is to have a single 32-bit container used by all 32-bit > software. With that approach all the 32-bit software would be able to > interact with the rest of the 32-bit system, there wouldn't be > segregation between them. > Yes, I was unclear about this, but that was where I was going with it. A single 32-bit container whose purpose was to share the 32-bit runtime. That being said, the counter-proposal of figuring out how to keep the layout the same as today but keeping the content in separate repositories is compelling and I'm investigating that further. > But we would need to consider how a 32-bit application starts other > programs via things like xdg-open. Would you have to have a 32-bit > browser installed so that you could click on links in 32-bit > applications? Would xdg-utils have to be installed on the system > twice, once in the 64-bit host and once in the 32-bit container? And > install things like Firefox and image viewers twice? Very good questions and I don't have all the answers right now, but again, I think the "separate repository" solution might be closer, as the end result should keep things in the same hierarchy. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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 the UsrMove >> > change >> > and would likely be solved the same way; by maintaining symlinks in the old >> > locations for some reasonable migration period. Given the enormous number >> > of >> > packages involved and the fact that it's not a simple directory rename, we >> > may >> > need to add a hack into rpmbuild to automatically generate these symlinks >> > in the >> > old location. >> > >> > * Switching to this layout might give a false (or possibly accurate, in >> > some >> > cases) impression that one could expect Debian/Ubuntu packages to function >> > "out >> > of the box" on Fedora (if using something like Alien). Education is key >> > here. >> [snip] >> >> For anyone who isn't familiar with this topic, you might find Debian's >> documentation useful: >> >> https://wiki.debian.org/Multiarch >> >> One could take it a step further and actually have target triplets the >> convey OS version of the libraries instead of the generic "-redhat-linux" >> part of the tuple. With a little rpath abuse apps compiled for F25 could >> find their shared libraries in an F25 specific directory and multiple >> versions of the same package could be installed at the same time, for >> different OS versions. This goes beyond Fedora, too: apps compiled for >> Debian could find their shared libraries in a Debian specific directory, >> even though it's a Fedora system that is booted. A lot of fiddly details >> and hand waving go here, but the end result would be really useful. > > Noo! Debian Multiarch is FHS incompatible, too ugly to live with and > doesn't bring benefits, it is just different. > Please don't introduce this into Fedora. 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). -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 expect libraries to be > > in > > the /usr/lib[64] paths. This would be a similar problem to the UsrMove > > change > > and would likely be solved the same way; by maintaining symlinks in the old > > locations for some reasonable migration period. Given the enormous number of > > packages involved and the fact that it's not a simple directory rename, we > > may > > need to add a hack into rpmbuild to automatically generate these symlinks > > in the > > old location. > > > > * Switching to this layout might give a false (or possibly accurate, in some > > cases) impression that one could expect Debian/Ubuntu packages to function > > "out > > of the box" on Fedora (if using something like Alien). Education is key > > here. > [snip] > > For anyone who isn't familiar with this topic, you might find Debian's > documentation useful: > > https://wiki.debian.org/Multiarch > > One could take it a step further and actually have target triplets the > convey OS version of the libraries instead of the generic "-redhat-linux" > part of the tuple. With a little rpath abuse apps compiled for F25 could > find their shared libraries in an F25 specific directory and multiple > versions of the same package could be installed at the same time, for > different OS versions. This goes beyond Fedora, too: apps compiled for > Debian could find their shared libraries in a Debian specific directory, > even though it's a Fedora system that is booted. A lot of fiddly details > and hand waving go here, but the end result would be really useful. Noo! Debian Multiarch is FHS incompatible, too ugly to live with and doesn't bring benefits, it is just different. Please don't introduce this into Fedora. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 > 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. We're currently building out an entirely new infrastructure to support modules; we'd like to take a look at what we did the first time and see if (with more experience and hindsight) we can do a better job now, and ideally one we can share between the two approaches. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 established in this extended conversation. My first >> proposal was one possible approach for this, but this second idea would solve >> the same problem, possibly with less jarring impact. > > While I fully understand how our current multilib system is a mess for the > build and release process (being in certain respects responsible), I'm leery > of using that to make drastic changes. > > The whole point of building an OS/module/etc for users is to keep the > complexity on the build side and out of the users hands - they don't care > whether half the packages switched from autoconf to meson, whether twenty > things are now written in Rust, or whether the entire python stack jumped > minor (or major!) versions. They just want the system to upgrade and the > software they use to keep working. > > If the multilib change only brings benefits to our build process and breaks > user cases without offering significant benefits to them, I can't see the > justification for it until we can offer end-user benefits (... ostree?). Part of the situation is that we're building a new build process to deal with modules. In that situation, we're trying to avoid some of the complexity that has grown up over the years with our traditional build system. What my goal is here is to figure out a strategy that can work for both efforts so we don't have two completely different workarounds for the same problem. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
- Original Message - > On 05/01/17 14:42 -0500, Randy Barlow wrote: > >On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote: > >> Which definitely changes how software is built. > > > >Containers also change the way software must be written in some cases, > >since they expect there to be one main process and don't expect that > >main process to interact with other "main" processes on the system. > >There are some program architectures that aren't well suited to be run > >in containers since containers expect programs to work in specific > >ways. I don't think they are general enough to cover all use cases. > > > >I also expect that users will not appreciate being forced to use > >containers if they want to keep being able to do things they can do > >today. Offering it to them as an option rather than the only solution > >is probably a friendlier approach. > > > That would certainly be a problem if the proposal was to run each > 32-bit application in its own container environment, but I think the > suggestion is to have a single 32-bit container used by all 32-bit > software. With that approach all the 32-bit software would be able to > interact with the rest of the 32-bit system, there wouldn't be > segregation between them. > > But we would need to consider how a 32-bit application starts other > programs via things like xdg-open. Would you have to have a 32-bit > browser installed so that you could click on links in 32-bit > applications? Would xdg-utils have to be installed on the system > twice, once in the 64-bit host and once in the 32-bit container? And > install things like Firefox and image viewers twice? I wonder how that would work when 1) you need access outside the sandbox (say to play audio through PulseAudio, which needs an ALSA 32-bit plugin), or 2) the 32-bit binary is a plugin (remember 32-bit Flash inside Firefox with the nppluginwrapper?). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On 05/01/17 14:42 -0500, Randy Barlow wrote: On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote: Which definitely changes how software is built. Containers also change the way software must be written in some cases, since they expect there to be one main process and don't expect that main process to interact with other "main" processes on the system. There are some program architectures that aren't well suited to be run in containers since containers expect programs to work in specific ways. I don't think they are general enough to cover all use cases. I also expect that users will not appreciate being forced to use containers if they want to keep being able to do things they can do today. Offering it to them as an option rather than the only solution is probably a friendlier approach. That would certainly be a problem if the proposal was to run each 32-bit application in its own container environment, but I think the suggestion is to have a single 32-bit container used by all 32-bit software. With that approach all the 32-bit software would be able to interact with the rest of the 32-bit system, there wouldn't be segregation between them. But we would need to consider how a 32-bit application starts other programs via things like xdg-open. Would you have to have a 32-bit browser installed so that you could click on links in 32-bit applications? Would xdg-utils have to be installed on the system twice, once in the 64-bit host and once in the 32-bit container? And install things like Firefox and image viewers twice? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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. > > > > > So, this thread provided a lot of feedback. I had anticipated that the > suggestion would not be universally accepted, but I didn't quite expect > quite > so... vehement a response. :-) > > > I'll attempt to summarize the conversation thus far: > > * By far, the most frequent concern was that it would break Wine and Steam. > > * Third-party software written only for 32-bit runtimes would likely > require > considerable hacking to continue working under such a system. > > * Cross-compilers wouldn't be able to work with this system without > significant > modification. > > > 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) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thursday, January 5, 2017, 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 > 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.) > > > ## Open Questions (non-exhaustive): > > * Can SSSD and systemd's 32-bit name-service modules work from within a > container, talking to their host's service? Without that, 32-bit containers > won't be able to resolve users, groups or hostnames. > > * Can we have 32-bit containers communicate with other local system APIs > such as > D-BUS on the host? > > * Do we need to care about 32-bit GUI applications on a 64-bit system? > Should we > decide that flatpak is the official answer for such cases? > > This proposal is more or less "let's make life a bit easier for us in expense of our users". Your proposal shifts the hacks to the users. There are still a lot of 32bit software out there. In stead of having it just work you are asking users to fiddle around with hacks / jumping through hoops. So your proposal would cause way more harm than good. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 > proposal was one possible approach for this, but this second idea would solve > the same problem, possibly with less jarring impact. While I fully understand how our current multilib system is a mess for the build and release process (being in certain respects responsible), I'm leery of using that to make drastic changes. The whole point of building an OS/module/etc for users is to keep the complexity on the build side and out of the users hands - they don't care whether half the packages switched from autoconf to meson, whether twenty things are now written in Rust, or whether the entire python stack jumped minor (or major!) versions. They just want the system to upgrade and the software they use to keep working. If the multilib change only brings benefits to our build process and breaks user cases without offering significant benefits to them, I can't see the justification for it until we can offer end-user benefits (... ostree?). Bill ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 are "multilib clean" (not intentionally) and > thus technically parallel-installable, but we never want to have them > parallel installed. > > How dnf behaves now if we enable both i866 and x86_64 repos? > Quite poorly, I'm afraid. I tried to cite some of the reasons under the === Separated Repositories === section in the previous email. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 >> distributions. > > What does SuSE do for multi-lib? Or Arch or Gentoo? I don't think > Fedora switching would mean a de-facto anything. > Hmm, assuming http://www.pilotlogic.com/sitejoom/index.php/wiki?id=398 remains accurate (found it in a Google search), it looks like most distros are doing some combination of /usr/lib[32|64]. Though of course, on some distros, /usr/lib == 64-bit and others it's 32-bit. So I think there's definitely value in the explicit approach that Debian takes. >> So if we were to go this route, it would mean a great deal of work fixing up >> hundreds (if not thousands) of spec files to add explicit architecture >> dependencies, or else new functionality in DNF/libsolv to ensure that >> architectures don't change in a transaction. Or, ideally, both. > > Why wouldn't you have the rpm macros package automatically include the > %{?_isa} suffix in all built packages? The RPMs are built in > arch-specific chroots, so if it was done automatically it would likely > just need a mass rebuild? Am I missing a reason that wouldn't work? > Off the cuff, I can think of at least one quick example: SSSD. SSSD has a server and client libraries for both architectures (so 32-bit and 64-bit processes can both access the name service). If we arbitrarily added %{?_isa} to the sssd-clients sub-package, that would mean that pulling in sssd-clients.i686 on a 64-bit install would force it to pull in the 32-bit SSSD service, which would be a filesystem-level conflict (both would attempt to provide /usr/bin/sssd, /usr/libexec/sssd_*, /var/lib/sss/* etc.). That being said, maybe there's value in making this similar to the autoprovides, where we can set a flag in the spec file to skip automatically adding it. Since this is probably the exceptional case, that might be cleaner. Although as I think about it further, we would have to figure out how to handle virtual Provides: as well... there's no obvious way to differentiate them during rpmbuild, because they're fundamentally just strings. It's probably doable, but it will complicate matters and needs to be kept in mind. >> I think there is a lot of potential with these ideas (and they're compatible >> with our plans for modularity as well). Would people be willing to >> participate >> in such a task if we were to undertake it? > > Can you elaborate on the modularity plans, or point to a thread or > documentation if you've already described it? > Well, the short version is that we want to keep 32-bit and 64-bit runtimes in separate modules. So if you wanted to install 32-bit support, you'd pull in the matching 32-bit enhancement module for the base runtime you have. There's no documentation for this so far, but I'm planning to write something up very soon (tomorrow, if I can free up the cycles). 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 proposal was one possible approach for this, but this second idea would solve the same problem, possibly with less jarring impact. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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] > == 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 the UsrMove change and would likely be solved the same way; by > maintaining symlinks in the old locations for some reasonable migration > period. Given the enormous number of packages involved and the fact that > it's not a simple directory rename, we may need to add a hack into > rpmbuild to automatically generate these symlinks in the old location. > > * Switching to this layout might give a false (or possibly accurate, in > some cases) impression that one could expect Debian/Ubuntu packages to > function "out of the box" on Fedora (if using something like Alien). > Education is key here. * This change contradicts the FHS. The FHS clearly specifies that arch-specific libdirs should be named lib*, not lib/*. (It is funny that Debian, which otherwise follows the FHS so strictly as to even have refused to use the commonly-used libexec because it was not in the FHS before 3.0, decided to violate the FHS unilaterally that way.) * This change is backwards-incompatible. IMHO, binary compatibility with Debian is not worth the backwards compatibility break, especially considering that they are the ones not following the FHS. * I do not see any practical advantage of Debian multiarch over FHS multilib. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 would > include the emergence of a de-facto standard for system layout between the > major > distributions. Isn't this just result of good marketing of "multi-arch" distros? Because I fail to see where that approach is superior compared to what we have. > * 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 are "multilib clean" (not intentionally) and thus technically parallel-installable, but we never want to have them parallel installed. How dnf behaves now if we enable both i866 and x86_64 repos? Pavel > Those two suggestions are not (to my mind) incompatible with one another and > their combination may indeed prove to be a superior solution to the one I > initially came up with and suggested. > > I feel it necessary to point out some of the (surmountable) issues that such a > transition would face. > > > == 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 the UsrMove change > and would likely be solved the same way; by maintaining symlinks in the old > locations for some reasonable migration period. Given the enormous number of > packages involved and the fact that it's not a simple directory rename, we may > need to add a hack into rpmbuild to automatically generate these symlinks in > the > old location. > > * Switching to this layout might give a false (or possibly accurate, in some > cases) impression that one could expect Debian/Ubuntu packages to function > "out > of the box" on Fedora (if using something like Alien). Education is key here. > > > == Separated Repositories == > > This one is actually a lot harder than it might appear at first look, mostly > due > to the way our packaging dependencies are written. In many (most?) cases of > arch-ful packages, their dependencies are likely to be specified without the > %{?_isa} suffix. As a result, if we were to just blindly add the i686 > repository > to a running x86_64 system, even at lower priority, there would be times when > an > update would attempt to pull in the wrong architecture's package (consider > situations where the i686 mirror the user is connected to may have synced > already, but their x86_64 mirror has not). The user would inadvertently pull > in > the wrong version of a dependency and their application or service might fail > to > start or function unexpectedly. > > So if we were to go this route, it would mean a great deal of work fixing up > hundreds (if not thousands) of spec files to add explicit architecture > dependencies, or else new functionality in DNF/libsolv to ensure that > architectures don't change in a transaction. Or, ideally, both. > > > > I think there is a lot of potential with these ideas (and they're compatible > with our plans for modularity as well). Would people be willing to participate > in such a task if we were to undertake it? > > Similarly, I'm sure there are other "gotchas" hidden here that I didn't > immediately come up with. What other issues am I missing? I assume we made the > decision to do /usr/lib[64] in the first place for good reasons; What were > they, > and are they still valid? > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
I'm wholeheartedly against this. I also view personally containers *just* as a thing to solve subset of real-world problems, but not a army knife for everything. IOW, enforcing users to use containers instead of multilib feature looks a bit hostile. Have other distros already done this movement? I'm almost sure we shouldn't pioneer this. IMO: multilib && Modularization efforts && containerization efforts shouldn't collide. More in-line comments ... On Thursday, January 5, 2017 11:03:50 AM CET Stephen Gallagher wrote: > ## 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. If that's a real issue, we should avoid working on hacks, and rather invent a new way to _declare_ some (sub)package is designed to be multilib, I filed this: https://pagure.io/pungi/issue/500 > * Less duplication of content in the mirror networks. That's not really duplication to me. > * 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). What's the reason to not have multilib in Base Runtime? Is that because it is hard to experiment with multilib in copr (rhbz#1393664) or what hacks are you referring to? The point of this remark is that there should be a way to minimize hacks. > * Requires us to maintain and keep up-to-date the 32-bit container base > images. This would be pros, but we should probably have 32-bit container anyways.. > ## 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. .. user apps -> this looks like absolute showstopper IMO. Even though there are also third-party package providers like skype -- where I would personally appreciate we either forced them to move to container or provide x86_64 packages (or if there was really sufficient open source alternative to make them obsolete).. But I'm afraid such third party would rather drop Fedora support, which would be bad especially for us.. Pavel > * 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.) > > > ## Open Questions (non-exhaustive): > > * Can SSSD and systemd's 32-bit name-service modules work from within a > container, talking to their host's service? Without that, 32-bit containers > won't be able to resolve users, groups or hostnames. > > * Can we have 32-bit containers communicate with other local system APIs such > as > D-BUS on the host? > > * Do we need to care about 32-bit GUI applications on a 64-bit system? Should > we > decide that flatpak is the official answer for such cases? > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 >>> 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. >>> >> >> >> So, this thread provided a lot of feedback. I had anticipated that the >> suggestion would not be universally accepted, but I didn't quite expect quite >> so... vehement a response. :-) >> >> >> I'll attempt to summarize the conversation thus far: >> >> * By far, the most frequent concern was that it would break Wine and Steam. >> >> * Third-party software written only for 32-bit runtimes would likely require >> considerable hacking to continue working under such a system. >> >> * Cross-compilers wouldn't be able to work with this system without >> significant >> modification. > > * Represents a significant change to how end-user developers will need > to build software. > >> 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. > > What does SuSE do for multi-lib? Or Arch or Gentoo? I don't think > Fedora switching would mean a de-facto anything. > SUSE does multilib in the same style we do. Arch and Gentoo use /usr/lib32 for 32-bit libraries, and /usr/lib64 for 64-bit libraries. Both distros are also working on /usr/libx32 for the x32 ABI support, so they're doing three ABIs in parallel, as opposed to our two. >> * Ship only one arch in the repositories and allow users to trivially enable >> the >> repositories for other arches through DNF if they have need. >> >> >> >> Those two suggestions are not (to my mind) incompatible with one another and >> their combination may indeed prove to be a superior solution to the one I >> initially came up with and suggested. >> >> I feel it necessary to point out some of the (surmountable) issues that such >> a >> transition would face. >> >> >> == 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 the UsrMove change >> and would likely be solved the same way; by maintaining symlinks in the old >> locations for some reasonable migration period. Given the enormous number of >> packages involved and the fact that it's not a simple directory rename, we >> may >> need to add a hack into rpmbuild to automatically generate these symlinks in >> the >> old location. >> >> * Switching to this layout might give a false (or possibly accurate, in some >> cases) impression that one could expect Debian/Ubuntu packages to function >> "out >> of the box" on Fedora (if using something like Alien). Education is key here. >> >> >> == Separated Repositories == >> >> This one is actually a lot harder than it might appear at first look, mostly >> due >> to the way our packaging dependencies are written. In many (most?) cases of >> arch-ful packages, their dependencies are likely to be specified without the >> %{?_isa} suffix. As a result, if we were to just blindly add the i686 >> repository >> to a running x86_64 system, even at lower priority, there would be times >> when an >> update would attempt to pull in the wrong architecture's package (consider >> situations where the i686 mirror the user is connected to may have synced >> already, but their x86_64 mirror has not). The user would inadvertently pull >> in >> the wrong version of a dependency and their application or service might >> fail to >> start or function unexpectedly. >> >> So if we were to go this route, it would mean a great deal of work fixing up >> hundreds (if not thousands) of spec files to add explicit architecture >> dependencies, or else new functionality in DNF/libsolv to ensure that >> architectures don't change in a transaction. Or, ideally, both. > > Why wouldn't you have the rpm macros package automatically include the > %{?_isa} suffix in all built packages? The RPMs are built in > arch-specific chroots, so if it was done automatically it would likely > just need a mass rebuild? Am I missing a reason that wouldn't work? > We build noarch packages in archful chroots, so we'd accidentally break noarch package b
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 5, 2017 at 4:40 PM, Japheth Cleaver wrote: > On 1/5/2017 9:12 AM, Jonathan Wakely wrote: >> >> On 05/01/17 09:56 -0700, Chris Murphy wrote: >>> >>> Teamviewer comes in an i686 only package for Fedora. So is there going >>> to be this interim approach, and then yet another change when they're >>> expected to use FlatPak? That's a lot of changes... And are these two >>> approaches compatible with the other platforms they target, or are >>> they just likely to drop the one it stops working on? >>> >>> I can hardly imagine Teamviewer is the only 32-bit only GUI program. >> >> >> There are all sorts of proprietary programs like Skype that are only >> provided as 32-bit packages (there's a "skypeforlinux" package which >> is 64-bit but it's an "alpha" release). >> >> Maybe it would work fine from inside a 32-bit container, I have no >> idea, but we should be careful not to make it harder for normal users >> to install and use software distributed outside Fedora. And not make >> it harder for ISVs to provide RPMs that work on Fedora with minimal >> effort. > > > I feel like if this happens it will hasten the day when those of us > primarily working in EL-variant land have to consider a need for a new, > EL-forward, RPM-based open source "community" OS. Can you elaborate why you think that? Particularly the "EL-forward" part. I don't understand how Stephen's line of thinking is not EL-forward. > Fedora's role of breaking all sorts of things because $shinyNewParadigm -- > moving further and further from the semblance of stability available in just > being an extrapolation of where RHEL and its derivatives end up -- does > create certain operational borders. Eventually that friction becomes > unbearable. If it's containers you are talking about, then I'm even more confused. You're aware that containers are a very important part of the Red Hat ecosystem today, right? The value add of any enterprise distribution is to take $shinyNewParadigm, nurture it upstream, focus on stability and performance of the technologies in it's own offerings, and provide support. Not having a vibrant community project where some of this innovation can incubate is crippling any enterprise OS's ability to remain flexible and relevant in the market place. The days of RHEL being _only_ the thing you use on large datacenter servers are pretty much already gone. It is that, and much more. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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. >> > > > So, this thread provided a lot of feedback. I had anticipated that the > suggestion would not be universally accepted, but I didn't quite expect quite > so... vehement a response. :-) > > > I'll attempt to summarize the conversation thus far: > > * By far, the most frequent concern was that it would break Wine and Steam. > > * Third-party software written only for 32-bit runtimes would likely require > considerable hacking to continue working under such a system. > > * Cross-compilers wouldn't be able to work with this system without > significant > modification. * Represents a significant change to how end-user developers will need to build software. > 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. What does SuSE do for multi-lib? Or Arch or Gentoo? I don't think Fedora switching would mean a de-facto anything. > * Ship only one arch in the repositories and allow users to trivially enable > the > repositories for other arches through DNF if they have need. > > > > Those two suggestions are not (to my mind) incompatible with one another and > their combination may indeed prove to be a superior solution to the one I > initially came up with and suggested. > > I feel it necessary to point out some of the (surmountable) issues that such a > transition would face. > > > == 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 the UsrMove change > and would likely be solved the same way; by maintaining symlinks in the old > locations for some reasonable migration period. Given the enormous number of > packages involved and the fact that it's not a simple directory rename, we may > need to add a hack into rpmbuild to automatically generate these symlinks in > the > old location. > > * Switching to this layout might give a false (or possibly accurate, in some > cases) impression that one could expect Debian/Ubuntu packages to function > "out > of the box" on Fedora (if using something like Alien). Education is key here. > > > == Separated Repositories == > > This one is actually a lot harder than it might appear at first look, mostly > due > to the way our packaging dependencies are written. In many (most?) cases of > arch-ful packages, their dependencies are likely to be specified without the > %{?_isa} suffix. As a result, if we were to just blindly add the i686 > repository > to a running x86_64 system, even at lower priority, there would be times when > an > update would attempt to pull in the wrong architecture's package (consider > situations where the i686 mirror the user is connected to may have synced > already, but their x86_64 mirror has not). The user would inadvertently pull > in > the wrong version of a dependency and their application or service might fail > to > start or function unexpectedly. > > So if we were to go this route, it would mean a great deal of work fixing up > hundreds (if not thousands) of spec files to add explicit architecture > dependencies, or else new functionality in DNF/libsolv to ensure that > architectures don't change in a transaction. Or, ideally, both. Why wouldn't you have the rpm macros package automatically include the %{?_isa} suffix in all built packages? The RPMs are built in arch-specific chroots, so if it was done automatically it would likely just need a mass rebuild? Am I missing a reason that wouldn't work? > I think there is a lot of potential with these ideas (and they're compatible > with our plans for modularity as well). Would people be willing to participate > in such a task if we were to undertake it? Can you elaborate on the modularity plans, or point to a thread or documentation if you've already described it? > Similarly, I'm sure there are other "gotchas" hidden here that I didn't > immediately come up with. What other issues am I missing? I assume we made the > decision to do /usr/lib[64] in the first place for good reasons
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 5, 2017 at 2:40 PM, Japheth Cleaver wrote: > I feel like if this happens it will hasten the day when those of us > primarily working in EL-variant land have to consider a need for a new, > EL-forward, RPM-based open source "community" OS. > > Fedora's role of breaking all sorts of things because $shinyNewParadigm -- > moving further and further from the semblance of stability available in just > being an extrapolation of where RHEL and its derivatives end up -- does > create certain operational borders. Eventually that friction becomes > unbearable. Uhh, I see this as something is degrading and inevitably going to fall apart. There's the spit and baling wire approach, where the ostrich maneuver would mean at least we wouldn't have to witness the aftermath. Or there's this other idea that Stephen had which sounded to me like it's trying to leverage learned things, not invent all shiny new stuff. It was a trial balloon anyway, so I wouldn't make it out to be more than grandiose than that. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 compiled to expect libraries to >> be in >> the /usr/lib[64] paths. This would be a similar problem to the UsrMove >> change >> and would likely be solved the same way; by maintaining symlinks in the >> old >> locations for some reasonable migration period. Given the enormous number >> of >> packages involved and the fact that it's not a simple directory rename, we >> may >> need to add a hack into rpmbuild to automatically generate these symlinks >> in the >> old location. >> >> * Switching to this layout might give a false (or possibly accurate, in >> some >> cases) impression that one could expect Debian/Ubuntu packages to function >> "out >> of the box" on Fedora (if using something like Alien). Education is key >> here. > > [snip] > > For anyone who isn't familiar with this topic, you might find Debian's > documentation useful: > > https://wiki.debian.org/Multiarch > > One could take it a step further and actually have target triplets the > convey OS version of the libraries instead of the generic "-redhat-linux" > part of the tuple. With a little rpath abuse apps compiled for F25 could > find their shared libraries in an F25 specific directory and multiple > versions of the same package could be installed at the same time, for > different OS versions. This goes beyond Fedora, too: apps compiled for > Debian could find their shared libraries in a Debian specific directory, > even though it's a Fedora system that is booted. A lot of fiddly details > and hand waving go here, but the end result would be really useful. > We wouldn't have to mess with the platform triple for that. We could simply add another namespace. For example: /usr/lib/ So, x86_64 libraries for Fedora 25 would go into /usr/lib/x86_64-linux-gnu/redhat/fedora/25/ Some handwavy magic there, and you could do this for a multitude of distros... -- 真実はいつも一つ!/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 the UsrMove change and would likely be solved the same way; by maintaining symlinks in the old locations for some reasonable migration period. Given the enormous number of packages involved and the fact that it's not a simple directory rename, we may need to add a hack into rpmbuild to automatically generate these symlinks in the old location. * Switching to this layout might give a false (or possibly accurate, in some cases) impression that one could expect Debian/Ubuntu packages to function "out of the box" on Fedora (if using something like Alien). Education is key here. [snip] For anyone who isn't familiar with this topic, you might find Debian's documentation useful: https://wiki.debian.org/Multiarch One could take it a step further and actually have target triplets the convey OS version of the libraries instead of the generic "-redhat-linux" part of the tuple. With a little rpath abuse apps compiled for F25 could find their shared libraries in an F25 specific directory and multiple versions of the same package could be installed at the same time, for different OS versions. This goes beyond Fedora, too: apps compiled for Debian could find their shared libraries in a Debian specific directory, even though it's a Fedora system that is booted. A lot of fiddly details and hand waving go here, but the end result would be really useful. -- Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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 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. >> > > > So, this thread provided a lot of feedback. I had anticipated that the > suggestion would not be universally accepted, but I didn't quite expect quite > so... vehement a response. :-) > > > I'll attempt to summarize the conversation thus far: > > * By far, the most frequent concern was that it would break Wine and Steam. > > * Third-party software written only for 32-bit runtimes would likely require > considerable hacking to continue working under such a system. > > * Cross-compilers wouldn't be able to work with this system without > significant > modification. > > > 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. > > > > Those two suggestions are not (to my mind) incompatible with one another and > their combination may indeed prove to be a superior solution to the one I > initially came up with and suggested. > > I feel it necessary to point out some of the (surmountable) issues that such a > transition would face. > > > == 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 the UsrMove change > and would likely be solved the same way; by maintaining symlinks in the old > locations for some reasonable migration period. Given the enormous number of > packages involved and the fact that it's not a simple directory rename, we may > need to add a hack into rpmbuild to automatically generate these symlinks in > the > old location. > The main breakage will be dealing with programs that use RPATH and expect 32-bit libs in /usr/lib (since we never moved 32-bit libs to /usr/lib32). Everything else is trivial to deal with (/usr/lib64 can just point to /usr/lib/x86_64-linux-gnu, for instance), but that will get tricky. Fortunately, we don't have much in the way of RPATH issues, so I don't expect this to be a big problem. We should probably also have the /usr/lib32 symlink added to point to /usr/lib/i386-linux-gnu for compatibility purposes, too (Gentoo, Arch, and several other families do use that, and there's no real cost to having the symlink there if we have full platform libdirs anyway). > * Switching to this layout might give a false (or possibly accurate, in some > cases) impression that one could expect Debian/Ubuntu packages to function > "out > of the box" on Fedora (if using something like Alien). Education is key here. > > > == Separated Repositories == > > This one is actually a lot harder than it might appear at first look, mostly > due > to the way our packaging dependencies are written. In many (most?) cases of > arch-ful packages, their dependencies are likely to be specified without the > %{?_isa} suffix. As a result, if we were to just blindly add the i686 > repository > to a running x86_64 system, even at lower priority, there would be times when > an > update would attempt to pull in the wrong architecture's package (consider > situations where the i686 mirror the user is connected to may have synced > already, but their x86_64 mirror has not). The user would inadvertently pull > in > the wrong version of a dependency and their application or service might fail > to > start or function unexpectedly. > > So if we were to go this route, it would mean a great deal of work fixing up > hundreds (if not thousands) of spec files to add explicit architecture > dependencies, or else new functionality in DNF/libsolv to ensure that > architectures don't change in a transaction. Or, ideally, both. > > There are definitely bugs here, as I've been integrating DNF into Mageia, and they follow this approach currently. There are some strange behaviors that can occur. Most of the issues have been dealt with, but there's still a few surprises there (and I've really got to get around to filing bugs for them, once I collect all the needed data!). >
Re: Proposal: Rethink Fedora multilib support
On 1/5/2017 9:12 AM, Jonathan Wakely wrote: On 05/01/17 09:56 -0700, Chris Murphy wrote: Teamviewer comes in an i686 only package for Fedora. So is there going to be this interim approach, and then yet another change when they're expected to use FlatPak? That's a lot of changes... And are these two approaches compatible with the other platforms they target, or are they just likely to drop the one it stops working on? I can hardly imagine Teamviewer is the only 32-bit only GUI program. There are all sorts of proprietary programs like Skype that are only provided as 32-bit packages (there's a "skypeforlinux" package which is 64-bit but it's an "alpha" release). Maybe it would work fine from inside a 32-bit container, I have no idea, but we should be careful not to make it harder for normal users to install and use software distributed outside Fedora. And not make it harder for ISVs to provide RPMs that work on Fedora with minimal effort. I feel like if this happens it will hasten the day when those of us primarily working in EL-variant land have to consider a need for a new, EL-forward, RPM-based open source "community" OS. Fedora's role of breaking all sorts of things because $shinyNewParadigm -- moving further and further from the semblance of stability available in just being an extrapolation of where RHEL and its derivatives end up -- does create certain operational borders. Eventually that friction becomes unbearable. -jc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 5, 2017 at 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 > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On 01/05/2017 08:03 AM, Stephen Gallagher wrote: ## 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. All of my 32-bit software is installed in $HOME/.local/share/Steam, I take it that under this proposal it would immediately stop working upon upgrading Fedora and never work again? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, 2017-01-05 at 17:02 +, Jonathan Wakely wrote: > Which definitely changes how software is built. Containers also change the way software must be written in some cases, since they expect there to be one main process and don't expect that main process to interact with other "main" processes on the system. There are some program architectures that aren't well suited to be run in containers since containers expect programs to work in specific ways. I don't think they are general enough to cover all use cases. I also expect that users will not appreciate being forced to use containers if they want to keep being able to do things they can do today. Offering it to them as an option rather than the only solution is probably a friendlier approach. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
Once upon a time, M. Edward (Ed) Borasky said: > But seriously ... aren't there plenty of distros that support older 32-bit > hardware ... enough so that Fedora can draw a line in the sand and say, > Fedora 27 will be ARM and 64-bit x86 only? Let Debian support all the other > stuff and run it in a Debian container? If I have to run Debian to use the software I need/want (for example, as others already mentioned in this thread, I use Teamviewer and Steam), then I'm not going to run Fedora as well. It isn't about 32-bit hardware, it is about 32-bit software. I'd love to be running a pure open source system, but in the real world, I can't. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 5, 2017 at 2:11 PM, M. Edward (Ed) Borasky wrote: > > > On Thu, Jan 5, 2017 at 10:50 AM Daniel J Walsh wrote: > >> >> Well we will be retired at that point, and playing shuffle board. > > > Well, I'm retired *now* and I'm still a Fedora end-user. ;-) > > But seriously ... aren't there plenty of distros that support older 32-bit > hardware ... enough so that Fedora can draw a line in the sand and say, > Fedora 27 will be ARM and 64-bit x86 only? Let Debian support all the other > stuff and run it in a Debian container? Um... no. Why would we drop the other alternative architectures that have worked diligently to release in lock-step with x86_64? I have a fundamental disagreement with that suggestion. > And speaking of Wine, how come the Windows 10 Linux subsystem only runs > Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows machine? I think you should start another thread about that topic. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 5, 2017 at 10:50 AM Daniel J Walsh wrote: > Well we will be retired at that point, and playing shuffle board. > Well, I'm retired *now* and I'm still a Fedora end-user. ;-) But seriously ... aren't there plenty of distros that support older 32-bit hardware ... enough so that Fedora can draw a line in the sand and say, Fedora 27 will be ARM and 64-bit x86 only? Let Debian support all the other stuff and run it in a Debian container? And speaking of Wine, how come the Windows 10 Linux subsystem only runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows machine? > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > -- How many people can stand on the shoulders of a giant before the giant collapses? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 5, 2017 at 1:42 PM, Dennis Gilmore wrote: > On jueves, 5 de enero de 2017 1:35:28 PM CST Josh Boyer wrote: >> On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore wrote: >> > On jueves, 5 de enero de 2017 11:03:50 AM CST 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 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. >> > >> > I am not opposed, however I think we should possibly just have people >> > enable the 32 bit x86 repo instead of your proposal >> >> Multilib exists on non-x86 architectures. Should this proposal gain >> traction, we need to consider the implications to those architectures. > its been killed off on all other arches. I stand corrected. For some reason I thought it still existed on ppc64, but that is clearly not the case. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, 05 Jan 2017 11:58:06 -0600 Dennis Gilmore wrote: > On jueves, 5 de enero de 2017 11:03:50 AM CST 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 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. > I am not opposed, however I think we should possibly just have people > enable the 32 bit x86 repo instead of your proposal exactly, such solution should deliver the same user experience Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
Stephen Gallagher wrote: > However, it still doesn't solve the problem that we have today, which is > that we have to do a lot of hacky shuffling around of packages in order to > take packages built in i686 and drop them onto the x86_64 repository. Then just have the users enable the 32-bit repository if they want 32-bit packages. IMHO, that would make sense. Forcing everybody who needs multilib to use containers, on the other hand, is a very bad idea. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On 01/05/2017 01:36 PM, Stephen John Smoogen wrote: > On 5 January 2017 at 13:31, Daniel J Walsh wrote: >>> You just described a fundamental change to how people would need to >>> build 32-bit applications locally. They don't have to install a >>> VM/chroot to do that today, they would in a containerized multilib >>> solution. I don't think it's fair to claim "Building of software >>> shouldn't be changed at all in most cases" with this proposal. >>> >>> Remember, not all software is built in mock or even as RPMs. End user >>> software developers will be impacted by the removal of existing >>> multilib. >>> >>> josh >> Sadly will we be hearing these same arguments 10 years from now... > Yes. We will. And in 10 years from now the inevitable backlash against > containers because they aren't new and nifty and had all these warts > that come from real life will be in full swing. [This doesn't mean > that containers will go away any more than they were completely new in > the first place but ideas that Multics (and other OS's had) in the > 1960/70's.] This is how software goes. > Well we will be retired at that point, and playing shuffle board. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On jueves, 5 de enero de 2017 1:35:28 PM CST Josh Boyer wrote: > On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore wrote: > > On jueves, 5 de enero de 2017 11:03:50 AM CST 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 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. > > > > I am not opposed, however I think we should possibly just have people > > enable the 32 bit x86 repo instead of your proposal > > Multilib exists on non-x86 architectures. Should this proposal gain > traction, we need to consider the implications to those architectures. its been killed off on all other arches. Dennis signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 5, 2017 at 1:31 PM, Daniel J Walsh wrote: > > > On 01/05/2017 01:26 PM, Josh Boyer wrote: >> On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher >> wrote: >>> On 01/05/2017 11:17 AM, Tom Hughes wrote: On 05/01/17 16:03, Stephen Gallagher wrote: > 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. You may be living in a "new container world" but that doesn't mean the rest of us (or our users) are. >>> By "new container world" I meant "a world where containers exist and can >>> offer a >>> complete 32-bit runtime" rather than a hacked-in multilib runtime. >>> > 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. On the face of it it sounds like a terrible idea but perhaps I have misunderstood the consequences. Can you explain what this would actually mean for an average software developer trying to build a 32 bit program? Take for example my day job where I'm developing a proprietary application on a Fedora workstation. Now mostly I use a 64 bit build of the software but we have a few databases we support where the vendor doesn't provide 64 bit libraries so I have to use a 32 bit build. Would this mean I had to do some special dance to enter a container environment in order to work with a 32 bit build rather than just telling our build scripts to use "gcc -m32" when compiling? >>> Building of software shouldn't be changed at all in most cases. The main >>> difference would be installation/deployment. The idea would be that instead >>> of >>> the 32-bit and 64-bit runtimes being installed directly in parallel on the >>> base >>> system, they would instead be installed into effectively a chroot with its >>> own >>> completely 32-bit runtime. >> You just described a fundamental change to how people would need to >> build 32-bit applications locally. They don't have to install a >> VM/chroot to do that today, they would in a containerized multilib >> solution. I don't think it's fair to claim "Building of software >> shouldn't be changed at all in most cases" with this proposal. >> >> Remember, not all software is built in mock or even as RPMs. End user >> software developers will be impacted by the removal of existing >> multilib. > Sadly will we be hearing these same arguments 10 years from now... I'm not suggesting we shouldn't change our multilib strategy. I'm saying we can't change it can claim that it won't impact end users. That is all. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On 5 January 2017 at 13:31, Daniel J Walsh wrote: > >> You just described a fundamental change to how people would need to >> build 32-bit applications locally. They don't have to install a >> VM/chroot to do that today, they would in a containerized multilib >> solution. I don't think it's fair to claim "Building of software >> shouldn't be changed at all in most cases" with this proposal. >> >> Remember, not all software is built in mock or even as RPMs. End user >> software developers will be impacted by the removal of existing >> multilib. >> >> josh > Sadly will we be hearing these same arguments 10 years from now... Yes. We will. And in 10 years from now the inevitable backlash against containers because they aren't new and nifty and had all these warts that come from real life will be in full swing. [This doesn't mean that containers will go away any more than they were completely new in the first place but ideas that Multics (and other OS's had) in the 1960/70's.] This is how software goes. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Proposal: Rethink Fedora multilib support
On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore wrote: > On jueves, 5 de enero de 2017 11:03:50 AM CST 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 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. > I am not opposed, however I think we should possibly just have people enable > the 32 bit x86 repo instead of your proposal Multilib exists on non-x86 architectures. Should this proposal gain traction, we need to consider the implications to those architectures. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org