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

[Richard W.M. Jones]

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

[Carlos O'Donell]

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

[Saleem Abdulrasool]

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

Yeah, we have a symbolic link `/usr/host` which 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!)

[Neal Gompa]

On Thu, Jan 12, 2017 at 6:11 PM, Kevin Kofler  wrote:
> Saleem Abdulrasool wrote:
>> First, we accepted the /usr-merge (for simplicity and since most Linux
>> distributions were doing so) -- not doing so would require two parallel
>> trees, but would not prohibit the same approach.  The next thing 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!)

[Kevin Kofler]

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

[Brendan Conoboy]

On 01/12/2017 06:49 AM, Neal Gompa wrote:

On Thu, Jan 12, 2017 at 9:26 AM, Brendan Conoboy  wrote:

On 01/11/2017 08:23 PM, Kevin Kofler wrote:


you must absolutely split the binaries (which would conflict with the
native
binaries) and the libraries (which you need to do your cross-compilation
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!)

[Saleem Abdulrasool]

Hello again,

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

[Saleem Abdulrasool]

Hi,

I think that an alternative approach that should be given some consideration is 
what I came up with for Exherbo.  The differences from FHS are pretty small, 
and fits very easily into autotools and CMake based packages as well.  There is 
the original motivational write up for this at: 
https://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!)

[Matthew Miller]

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

[Kevin Kofler]

Brendan Conoboy wrote:
> Hey, I can agree to that.  Can you agree that /usr/bin could then be a
> symlink or linkfarm to /usr/target/usr/bin?

No. It does not make sense to put the native architecture into a sysroot, 
that would be a violation of the FHS. Sysroots are only for the special use 
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!)

[Neal Gompa]

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

[Brendan Conoboy]

On 01/11/2017 08:23 PM, Kevin Kofler wrote:

you must absolutely split the binaries (which would conflict with the native
binaries) and the libraries (which you need to do your cross-compilation or
to run your non-native binaries) into separate subpackages wherever packages
currently ship both, or 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!)

[Oron Peled]

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

[Kevin Kofler]

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

This is wrong, because, as you wrote:

> Binaries are not 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 (Take Two!)

[Brendan Conoboy]

On 01/10/2017 01:36 AM, Florian Weimer wrote:

On 01/09/2017 03:37 PM, Dennis Gilmore wrote:


the only reason that aarch64 used /usr/lib64 was so it looked more like
 x86_64 from a user perspective, there is 64 bit arches like alpha that
use /usr/lib for their libraries.


We'll see soon what the 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!)

[Brendan Conoboy]

On 01/10/2017 07:49 AM, Langdon White wrote:
[snip]

Exactly, yes, a huge *potential* problem. However, it is fixable with
policy and changeable by exception. Just because we can have 40
versions of one thing doesn't mean Fedora will allow that. However, if
there is a genuinely good reason and we 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!)]

[Florian Weimer]

On 01/10/2017 11:49 AM, Matthew Miller wrote:

On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote:

Apache httpd and KDE are very interesting examples.  Both KDE and
Apache httpd integrate with Subversion, on two levels: KDE has
Subversion client support, Apache httpd has server 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!)

[Langdon White]

On Tue, Jan 10, 2017 at 8:20 AM, Ian Malone  wrote:

> On 10 January 2017 at 10:08, Florian Weimer  wrote:
> > On 01/08/2017 01:52 AM, Kevin Kofler wrote:
> >>
> >> Brendan Conoboy wrote:
> >>>
> >>> Enhancing interoperability increases the reach of Fedora and doesn't
> >>> require a bit of 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!)

[Ian Malone]

On 10 January 2017 at 10:08, Florian Weimer  wrote:
> On 01/08/2017 01:52 AM, Kevin Kofler wrote:
>>
>> Brendan Conoboy wrote:
>>>
>>> Enhancing interoperability increases the reach of Fedora and doesn't
>>> require a bit of compromise on the the Freedom principle.
>>
>>
>> Splitting a single well-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!)

[Matthew Miller]

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

[Igor Gnatenko]

On Tue, Jan 10, 2017 at 11:49 AM, Matthew Miller
 wrote:
>
> On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote:
> > Apache httpd and KDE are very interesting examples.  Both KDE and
> > Apache httpd integrate with Subversion, on two levels: KDE has
> > Subversion client support, Apache 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!)]

[Matthew Miller]

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

[Florian Weimer]

On 01/10/2017 12:06 AM, langdon wrote:


Now, there are some use cases where the interop of the components is
very important and a distribution enables this because all the things
are tightly integrated. However, there is no particularly good reason
for httpd and kde to be tightly integrated. Why 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!)

[Florian Weimer]

On 01/08/2017 01:52 AM, Kevin Kofler wrote:

Brendan Conoboy wrote:

Enhancing interoperability increases the reach of Fedora and doesn't
require a bit of compromise on the the Freedom principle.


Splitting a single well-integrated distribution (where all the pieces are
known to work well 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!)

[Florian Weimer]

On 01/09/2017 03:37 PM, Dennis Gilmore wrote:


the only reason that aarch64 used /usr/lib64 was so it looked more like
 x86_64 from a user perspective, there is 64 bit arches like alpha that
use /usr/lib for their libraries.


We'll see soon what the non-multiarch layout will be for aarch64 (but 
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!)

[Richard W.M. Jones]

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

[Richard W.M. Jones]

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

[langdon]

On 01/09/2017 10:56 AM, Matthew Miller wrote:

On Sat, Jan 07, 2017 at 03:47:56AM +0100, Kevin Kofler wrote:

I don't buy this sort of alarmist bulldung that keeps being claimed with no
evidence whatsoever to justify radical changes to what Fedora is all about,
such as:
* promoting proprietary 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) 

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

[Matthew Miller]

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

[Dennis Gilmore]

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

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

[Neal Gompa]

On Mon, Jan 9, 2017 at 3:20 AM, Jakub Jelinek  wrote:
> On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote:
>> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote:
>> > On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
>> > > Two suggestions were raised 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!)

[Jakub Jelinek]

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

[Neal Gompa]

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

[M. Edward (Ed) Borasky]

On Sat, Jan 7, 2017 at 3:16 PM Richard W.M. Jones  wrote:

> Partly because there exist more than 2 architectures (think:
> RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various
> CPU features like SSE or AVX compiled in and out).  Partly because
> there will be fewer differences 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!)

[Kevin Kofler]

Brendan Conoboy wrote:
> Enhancing interoperability increases the reach of Fedora and doesn't
> require a bit of compromise on the the Freedom principle.

Splitting a single well-integrated distribution (where all the pieces are 
known to work well together) into a bunch of loosely-coupled black-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!)

[Kevin Kofler]

Oron Peled wrote:

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

[Oron Peled]

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

[Brendan Conoboy]

On 01/06/2017 06:47 PM, Kevin Kofler wrote:

I think that by destroying what Fedora is all about, we will become a
footnote in history. On the other hand, sticking to our principles (Freedom)
and to our technical strengths (an integrated distribution of integrated
packages) will keep us relevant 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!)

[Richard W.M. Jones]

On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote:
> On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
> > Two suggestions were raised as alternatives to the container approach:
> > 
> > * Switch to using the Debian style of multi-arch layout, which instead of
> > /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 (Take Two!)

[Kevin Kofler]

Matthew Miller wrote:
> But if that's *all* we do, we're going to be a footnote in history.

I don't buy this sort of alarmist bulldung that keeps being claimed with no 
evidence whatsoever to justify radical changes to what Fedora is all about, 
such as:
* promoting proprietary drivers (making 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!)

[Matthew Miller]

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

[Brendan Conoboy]

On 01/06/2017 08:14 AM, Neal Gompa wrote:
[snip]

Much of what I would have said has been said by Oron (some of this
I've said in earlier parts of this thread, as well).  But the bigger
thing is that it makes it much easier to bootstrap new architectures
for Fedora, too, as we can start from 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!)

[Kevin Kofler]

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

[Kevin Kofler]

Stephen Gallagher wrote:
> As Bill pointed out, things "just work" for users right now and that's
> something we'd like to avoid breaking. However, that does *not* mean that
> it is trivial to do on the build side. We're currently building out an
> entirely new infrastructure to support modules; we'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!)

[Kevin Kofler]

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

[Kevin Kofler]

Neal Gompa wrote:
> I'd be happier if we just moved 32-bit libraries into /usr/lib32. That
> way /usr/lib can be only noarch libs (like noarch Python things, and
> stuff).

Noarch stuff should NOT be in /usr/lib to begin with! True noarch stuff 
should be in /usr/share. Arch-colored binaries should 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!)

[Tom Hughes]

On 06/01/17 13:33, Stephen Gallagher wrote:

On 01/06/2017 08:04 AM, Jakub Jelinek wrote:

On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:


For anyone who isn't familiar with this topic, you might find Debian's
documentation useful:

https://wiki.debian.org/Multiarch

One could 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!)

[Igor Gnatenko]

On Jan 6, 2017 5:16 PM, "Neal Gompa"  wrote:

On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled  wrote:
> On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote:
>
>> ...
>
>> * I do not see any practical advantage of Debian multiarch over FHS
>
>> multilib.
>
>
>
> Good question, multiarch is a huge 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!)

[Neal Gompa]

On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled  wrote:
> On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote:
>
>> ...
>
>> * I do not see any practical advantage of Debian multiarch over FHS
>
>> multilib.
>
>
>
> Good question, multiarch is a huge win for *embedded* developers.
>
>
>
> Let me 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 (Take Two!)

[Oron Peled]

On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote:
> ...
> * I do not see any practical advantage of Debian multiarch over FHS
>   multilib.

Good question, multiarch is a huge win for *embedded* developers.

Let me give real life example from my $day job:
 * We build stuff for arm and x86_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!)

[Matthew Miller]

On Fri, Jan 06, 2017 at 02:45:15PM +0100, drago01 wrote:
> because out of sync repositories. + Minor annoyances like additional
> (duplicated) meta data that you have to deal with (bandwidth, time to
> install packages / updates).

This is a good point; we're already pretty much awful on this point,
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!)

[Stephen Gallagher]

On 01/06/2017 08:45 AM, drago01 wrote:
> On Fri, Jan 6, 2017 at 2:24 PM, Stephen Gallagher  wrote:
>> On 01/06/2017 08:07 AM, drago01 wrote:
>>> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher  
>>> wrote:
 On 01/06/2017 01:08 AM, drago01 wrote:
>
> Two suggestions were raised as 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!)

[drago01]

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

 Two suggestions were raised as alternatives to the container approach:

 * 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!)

[Stephen Gallagher]

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

[Stephen Gallagher]

On 01/06/2017 08:07 AM, drago01 wrote:
> On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher  wrote:
>> On 01/06/2017 01:08 AM, drago01 wrote:
>>>
>>> Two suggestions were raised as alternatives to the container approach:
>>>
>>> * Switch to using the Debian style of multi-arch layout, which 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!)

[drago01]

On Fri, Jan 6, 2017 at 1:58 PM, Stephen Gallagher  wrote:
> On 01/06/2017 01:08 AM, drago01 wrote:
>>
>> Two suggestions were raised as alternatives to the container approach:
>>
>> * Switch to using the Debian style of multi-arch layout, which instead of
>> /usr/lib and /usr/lib64 uses /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 (Take Two!)

[Neal Gompa]

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

[Jakub Jelinek]

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

[Stephen Gallagher]

On 01/06/2017 01:08 AM, drago01 wrote:
> 
> Two suggestions were raised as alternatives to the container approach:
> 
> * Switch to using the Debian style of multi-arch layout, which instead of
> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this 
> would
> 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!)

[Stephen Gallagher]

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

[drago01]

On Thursday, January 5, 2017, Stephen Gallagher  wrote:

> On 01/05/2017 11:03 AM, Stephen Gallagher wrote:
> > # Overview
> >
> > For many years, Fedora has supported multilib by carrying
> parallel-installable
> > libraries in /usr/lib[64]. This was necessary for a very long time in
> order to
> > 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 (Take Two!)

[Bill Nottingham]

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

[Stephen Gallagher]

On 01/05/2017 08:47 PM, Pavel Raiskup wrote:
>> * Ship only one arch in the repositories and allow users to trivially
>> enable the repositories for other arches through DNF if they have need.
> 
> Hms, that's promising.  I don't see any obvious issue here, only that
> there might be packages that 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!)

[Stephen Gallagher]

On 01/05/2017 07:20 PM, Josh Boyer wrote:

>> * Switch to using the Debian style of multi-arch layout, which instead of
>> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this would
>> include the emergence of a de-facto standard for system layout between the 
>> major
>> 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!)

[Kevin Kofler]

Stephen Gallagher wrote:
> * Switch to using the Debian style of multi-arch layout, which instead of
> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this
> would include the emergence of a de-facto standard for system layout
> between the major distributions.
[snip]
> == multi-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!)

[Pavel Raiskup]

On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
> Two suggestions were raised as alternatives to the container approach:
> 
> * Switch to using the Debian style of multi-arch layout, which instead of
> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this 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 (Take Two!)

[Neal Gompa]

On Thu, Jan 5, 2017 at 7:20 PM, Josh Boyer  wrote:
> On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher  wrote:
>> On 01/05/2017 11:03 AM, Stephen Gallagher wrote:
>>> # Overview
>>>
>>> For many years, Fedora has supported multilib by carrying 
>>> parallel-installable
>>> libraries in /usr/lib[64]. 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 

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

[Josh Boyer]

On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher  wrote:
> On 01/05/2017 11:03 AM, Stephen Gallagher wrote:
>> # Overview
>>
>> For many years, Fedora has supported multilib by carrying 
>> parallel-installable
>> libraries in /usr/lib[64]. This was necessary for a very long time in order 
>> to
>> 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 

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

[Neal Gompa]

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

[Brendan Conoboy]

On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
[snip]

== multi-arch layout ==
* Moving the locations of all of the system libraries would potentially still
break third-party applications that were compiled to expect libraries to be in
the /usr/lib[64] paths. This would be a similar problem to 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!)

[Neal Gompa]

On Thu, Jan 5, 2017 at 5:08 PM, Stephen Gallagher  wrote:
> On 01/05/2017 11:03 AM, Stephen Gallagher wrote:
>> # Overview
>>
>> For many years, Fedora has supported multilib by carrying 
>> parallel-installable
>> libraries in /usr/lib[64]. This was necessary for a very long time in order 
>> to
>> 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 

Proposal: Rethink Fedora multilib support (Take Two!)

[Stephen Gallagher]

On 01/05/2017 11:03 AM, Stephen Gallagher wrote:
> # Overview
>
> For many years, Fedora has supported multilib by carrying parallel-installable
> libraries in /usr/lib[64]. This was necessary for a very long time in order to
> support 32-bit applications running on a 64-bit deployment. However, in 
> 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.

* 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?



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org