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 +
On 01/09/2017 08:18 PM, Richard W.M. Jones wrote:
> On Mon, Jan 09, 2017 at 09:20:20AM +0100, Jakub Jelinek wrote:
>> On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote:
>>> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote:
On Thursday, January 5, 2017 5:08:16 PM C
> On Thu, Jan 12, 2017 at 6:11 PM, Kevin Kofler wrote:
>
> The sysroot approach could still work in an "FHS-compatible" way by
> symlinking everything back. FHS permits symlinks to represent a
> traditional tree in non-traditional structures.
Yeah, we have a symbolic link `/usr/host` which point
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
Saleem Abdulrasool wrote:
> First, we accepted the /usr-merge (for simplicity and since most Linux
> distributions were doing so) -- not doing so would require two parallel
> trees, but would not prohibit the same approach. The next thing was to
> introduce a "namespace" within the filesystem layo
On 01/12/2017 06:49 AM, Neal Gompa wrote:
On Thu, Jan 12, 2017 at 9:26 AM, Brendan Conoboy wrote:
On 01/11/2017 08:23 PM, Kevin Kofler wrote:
you must absolutely split the binaries (which would conflict with the
native
binaries) and the libraries (which you need to do your cross-compilation
o
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
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
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
Brendan Conoboy wrote:
> Hey, I can agree to that. Can you agree that /usr/bin could then be a
> symlink or linkfarm to /usr/target/usr/bin?
No. It does not make sense to put the native architecture into a sysroot,
that would be a violation of the FHS. Sysroots are only for the special use
case
On Thu, Jan 12, 2017 at 9:26 AM, Brendan Conoboy wrote:
> On 01/11/2017 08:23 PM, Kevin Kofler wrote:
>>
>> you must absolutely split the binaries (which would conflict with the
>> native
>> binaries) and the libraries (which you need to do your cross-compilation
>> or
>> to run your non-native bi
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
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
Neal Gompa wrote:
> It's not true that we need to change anything (as Kevin Kofler
> suggested earlier in the thread) for this to be useful. There is no
> policy change required for this to be an improvement over the
> situation today.
This is wrong, because, as you wrote:
> Binaries are not dupl
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
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
On 01/10/2017 11:49 AM, Matthew Miller wrote:
On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote:
Apache httpd and KDE are very interesting examples. Both KDE and
Apache httpd integrate with Subversion, on two levels: KDE has
Subversion client support, Apache httpd has server suppor
On Tue, Jan 10, 2017 at 8:20 AM, Ian Malone wrote:
> On 10 January 2017 at 10:08, Florian Weimer wrote:
> > On 01/08/2017 01:52 AM, Kevin Kofler wrote:
> >>
> >> Brendan Conoboy wrote:
> >>>
> >>> Enhancing interoperability increases the reach of Fedora and doesn't
> >>> require a bit of comprom
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-
On Mon, Jan 09, 2017 at 06:06:24PM -0500, langdon wrote:
> I also am not sure I am comfortable with the move toward exposing
> proprietary software that we have been considering/implementing.
> However, I do think there is some benefit to being able to show
> firefox next to chrome when someone loo
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
On Tue, Jan 10, 2017 at 11:23:21AM +0100, Florian Weimer wrote:
> Apache httpd and KDE are very interesting examples. Both KDE and
> Apache httpd integrate with Subversion, on two levels: KDE has
> Subversion client support, Apache httpd has server support. And
> Subversion is implemented using a
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
On 01/08/2017 01:52 AM, Kevin Kofler wrote:
Brendan Conoboy wrote:
Enhancing interoperability increases the reach of Fedora and doesn't
require a bit of compromise on the the Freedom principle.
Splitting a single well-integrated distribution (where all the pieces are
known to work well togethe
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
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 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
On 01/09/2017 10:56 AM, Matthew Miller wrote:
On Sat, Jan 07, 2017 at 03:47:56AM +0100, Kevin Kofler wrote:
I don't buy this sort of alarmist bulldung that keeps being claimed with no
evidence whatsoever to justify radical changes to what Fedora is all about,
such as:
* promoting proprietary dri
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
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
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
On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote:
> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote:
> > On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
> > > Two suggestions were raised as alternatives to the container approach:
> > >
> > > * S
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
On Sat, Jan 7, 2017 at 3:16 PM Richard W.M. Jones wrote:
> Partly because there exist more than 2 architectures (think:
> RV64G/RV64GC/RV128G, ARMv5/6/7/8, or less esoterically, having various
> CPU features like SSE or AVX compiled in and out). Partly because
> there will be fewer differences b
Brendan Conoboy wrote:
> Enhancing interoperability increases the reach of Fedora and doesn't
> require a bit of compromise on the the Freedom principle.
Splitting a single well-integrated distribution (where all the pieces are
known to work well together) into a bunch of loosely-coupled black-bo
Oron Peled wrote:
> On Friday, 6 January 2017 19:02:16 IST Kevin Kofler wrote:
>> The right way to do cross toolchains is to cross-build sysrooted packages
>> from source in dedicated cross packages, which is how the Fedora cross
>> toolchains work. Mixing binaries for completely different machine
On Friday, 6 January 2017 19:02:16 IST Kevin Kofler wrote:
> The right way to do cross toolchains is to cross-build sysrooted packages
> from source in dedicated cross packages, which is how the Fedora cross
> toolchains work. Mixing binaries for completely different machines in the
> same direc
On 01/06/2017 06:47 PM, Kevin Kofler wrote:
I think that by destroying what Fedora is all about, we will become a
footnote in history. On the other hand, sticking to our principles (Freedom)
and to our technical strengths (an integrated distribution of integrated
packages) will keep us relevant f
On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote:
> On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
> > Two suggestions were raised as alternatives to the container approach:
> >
> > * Switch to using the Debian style of multi-arch layout, which instead of
> > /us
Matthew Miller wrote:
> But if that's *all* we do, we're going to be a footnote in history.
I don't buy this sort of alarmist bulldung that keeps being claimed with no
evidence whatsoever to justify radical changes to what Fedora is all about,
such as:
* promoting proprietary drivers (making the
On Fri, Jan 06, 2017 at 07:14:58PM +0100, Kevin Kofler wrote:
> > This is a good point; we're already pretty much awful on this point,
> > and let's not make it worse. (On the other hand, modularity has the
> > potential to help significantly on this point, as you should't need
> > detailed metadat
On 01/06/2017 08:14 AM, Neal Gompa wrote:
[snip]
Much of what I would have said has been said by Oron (some of this
I've said in earlier parts of this thread, as well). But the bigger
thing is that it makes it much easier to bootstrap new architectures
for Fedora, too, as we can start from libra
Matthew Miller wrote:
> This is a good point; we're already pretty much awful on this point,
> and let's not make it worse. (On the other hand, modularity has the
> potential to help significantly on this point, as you should't need
> detailed metadata about what's _inside_ a module at runtime in n
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
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
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
On 06/01/17 13:33, Stephen Gallagher wrote:
On 01/06/2017 08:04 AM, Jakub Jelinek wrote:
On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:
For anyone who isn't familiar with this topic, you might find Debian's
documentation useful:
https://wiki.debian.org/Multiarch
One could t
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
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
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_
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
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
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:
>>
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
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
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
On Fri, Jan 6, 2017 at 8:04 AM, Jakub Jelinek wrote:
> On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:
>> On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
>> [snip]
>> > == multi-arch layout ==
>> > * Moving the locations of all of the system libraries would potentially
>> > stil
On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:
> On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
> [snip]
> > == multi-arch layout ==
> > * Moving the locations of all of the system libraries would potentially
> > still
> > break third-party applications that were compiled to ex
On 01/06/2017 01:08 AM, drago01 wrote:
>
> Two suggestions were raised as alternatives to the container approach:
>
> * Switch to using the Debian style of multi-arch layout, which instead of
> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this
> would
> incl
On 01/05/2017 10:35 PM, Bill Nottingham wrote:
> Stephen Gallagher (sgall...@redhat.com) said:
>> The main reason for this is trying to simplify the module-building process.
>> We
>> really don't want to attempt to build both arches within the same buildroot
>> for
>> most of the reasons we've e
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
>
Stephen Gallagher (sgall...@redhat.com) said:
> The main reason for this is trying to simplify the module-building process. We
> really don't want to attempt to build both arches within the same buildroot
> for
> most of the reasons we've established in this extended conversation. My first
> prop
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
On 01/05/2017 07:20 PM, Josh Boyer wrote:
>> * Switch to using the Debian style of multi-arch layout, which instead of
>> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this would
>> include the emergence of a de-facto standard for system layout between the
>> major
>> distrib
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-
On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
> Two suggestions were raised as alternatives to the container approach:
>
> * Switch to using the Debian style of multi-arch layout, which instead of
> /usr/lib and /usr/lib64 uses /usr/lib/$ARCH-linux-gnu. Benefits to this woul
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]
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
>
On Thu, Jan 5, 2017 at 6:08 PM, Brendan Conoboy wrote:
> On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
> [snip]
>>
>> == multi-arch layout ==
>> * Moving the locations of all of the system libraries would potentially
>> still
>> break third-party applications that were compiled to expect librar
On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
[snip]
== multi-arch layout ==
* Moving the locations of all of the system libraries would potentially still
break third-party applications that were compiled to expect libraries to be in
the /usr/lib[64] paths. This would be a similar problem to t
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
>
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
72 matches
Mail list logo
