10:03 a.m.
# Overview
For many years, Fedora has supported multilib by carrying parallel-installable
libraries in /usr/lib[64]. This was necessary for a very long time in order to
support 32-bit applications running on a 64-bit deployment. However, in today's
new container world, there is a whole new option.
I'd like to propose that we consider moving away from our traditional approach
to multilib in favor of recommending the use of a 32-bit container runtime when
needed on a 64-bit host.
## Advantages
* Simplification of build-tree creation. We wouldn't have to maintain the lists
and hacks that are required to make sure that multilib packages land in the
correct repositories.
* Less duplication of content in the mirror networks.
* It will be simpler to create module content without having to reimplement all
the multilib hacks of above. This is directly relevant to the Base Runtime
module, whose prototype is today intentionally limited to the primary
architecture (no multilib).
* Requires us to maintain and keep up-to-date the 32-bit container base images.
## Disadvantages
* If we eliminate multilib entirely, all applications that use 32-bit libs will
have to either install a 32-bit host OS or install into a container. This may be
a difficult transition for some users.
* Mitigation: develop and maintain tools to ease this transition.
* It is unlikely that any clean upgrade path would exist. (We could make it
*technically* possible, but likely not without breaking 32-bit software not
installed by RPM.
* Requires us to maintain and keep up-to-date the 32-bit container base images.
(Yes, this is both an advantage and disadvantage.)
## Open Questions (non-exhaustive):
* Can SSSD and systemd's 32-bit name-service modules work from within a
container, talking to their host's service? Without that, 32-bit containers
won't be able to resolve users, groups or hostnames.
* Can we have 32-bit containers communicate with other local system APIs such as
D-BUS on the host?
* Do we need to care about 32-bit GUI applications on a 64-bit system? Should we
decide that flatpak is the official answer for such cases?
10:15 a.m.
On 01/05/2017 10:03 AM, Stephen Gallagher wrote:
* Do we need to care about 32-bit GUI applications on a 64-bit
system? Should we
decide that flatpak is the official answer for such cases?
I care. What impact would this have on Wine? If users are unable to use 32-bit
Windows apps, which are still a nice majority of apps, they'll quickly abandon
Fedora. Eventually that majority will get switched, but I don't see it happening for
at least 2-3 more years.
10:19 a.m.
On 01/05/2017 11:15 AM, Michael Cronenworth wrote:
On 01/05/2017 10:03 AM, Stephen Gallagher wrote:
> * Do we need to care about 32-bit GUI applications on a 64-bit system? Should we
> decide that flatpak is the official answer for such cases?
I care. What impact would this have on Wine? If users are unable to use 32-bit
Windows apps, which are still a nice majority of apps, they'll quickly abandon
Fedora. Eventually that majority will get switched, but I don't see it happening
for at least 2-3 more years.
Sorry, using the word "care" there was poorly phrased. I meant more like
"are
there 32-bit GUI applications that are very important and couldn't be made to
fit this new approach?". Wine is an interesting example I had not considered.
Are we certain that it couldn't be run from within a container, though? Possibly
via a wrapper?
10:35 a.m.
On 01/05/2017 10:19 AM, Stephen Gallagher wrote:
Are we certain that it couldn't be run from within a container,
though? Possibly
via a wrapper?
I would have to investigate because I have never had a need to install a container.
I've never gotten on board the "container train." :)
My main concern would be the ability to run 32-bit graphical applications [games].
Would access to Mesa, NVIDIA proprietary, and AMDGPU-PRO proprietary drivers and
libraries be as easy to setup as it is today?
10:39 a.m.
On 01/05/2017 11:35 AM, Michael Cronenworth wrote:
On 01/05/2017 10:19 AM, Stephen Gallagher wrote:
> Are we certain that it couldn't be run from within a container, though? Possibly
> via a wrapper?
I would have to investigate because I have never had a need to install a
container. I've never gotten on board the "container train." :)
My main concern would be the ability to run 32-bit graphical applications
[games]. Would access to Mesa, NVIDIA proprietary, and AMDGPU-PRO proprietary
drivers and libraries be as easy to setup as it is today?
"Would access to Mesa, NVIDIA proprietary, and AMDGPU-PRO proprietary drivers
and libraries be as easy to setup as it is today?"
Welp, there's LWN's quote of the week! ;-)
Kidding aside, you make a good point. Part of the reason for starting this
conversation is to figure out where the biggest pain points would be. Clearly,
Wine and third-party games are going to be one of those points and need
consideration.
I don't know enough about the low-level here to give a productive answer, but I
think this helps figure out which conversations we need to have.
10:56 a.m.
On Thu, Jan 5, 2017 at 9:19 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 01/05/2017 11:15 AM, Michael Cronenworth wrote:
> On 01/05/2017 10:03 AM, Stephen Gallagher wrote:
>> * Do we need to care about 32-bit GUI applications on a 64-bit system? Should we
>> decide that flatpak is the official answer for such cases?
>
> I care. What impact would this have on Wine? If users are unable to use 32-bit
> Windows apps, which are still a nice majority of apps, they'll quickly abandon
> Fedora. Eventually that majority will get switched, but I don't see it happening
> for at least 2-3 more years.
Sorry, using the word "care" there was poorly phrased. I meant more like
"are
there 32-bit GUI applications that are very important and couldn't be made to
fit this new approach?". Wine is an interesting example I had not considered.
Are we certain that it couldn't be run from within a container, though? Possibly
via a wrapper?
Teamviewer comes in an i686 only package for Fedora. So is there going
to be this interim approach, and then yet another change when they're
expected to use FlatPak? That's a lot of changes... And are these two
approaches compatible with the other platforms they target, or are
they just likely to drop the one it stops working on?
I can hardly imagine Teamviewer is the only 32-bit only GUI program.
--
Chris Murphy
11:12 a.m.
On 05/01/17 09:56 -0700, Chris Murphy wrote:
Teamviewer comes in an i686 only package for Fedora. So is there
going
to be this interim approach, and then yet another change when they're
expected to use FlatPak? That's a lot of changes... And are these two
approaches compatible with the other platforms they target, or are
they just likely to drop the one it stops working on?
I can hardly imagine Teamviewer is the only 32-bit only GUI program.
There are all sorts of proprietary programs like Skype that are only
provided as 32-bit packages (there's a "skypeforlinux" package which
is 64-bit but it's an "alpha" release).
Maybe it would work fine from inside a 32-bit container, I have no
idea, but we should be careful not to make it harder for normal users
to install and use software distributed outside Fedora. And not make
it harder for ISVs to provide RPMs that work on Fedora with minimal
effort.
3:40 p.m.
On 1/5/2017 9:12 AM, Jonathan Wakely wrote:
On 05/01/17 09:56 -0700, Chris Murphy wrote:
> Teamviewer comes in an i686 only package for Fedora. So is there going
> to be this interim approach, and then yet another change when they're
> expected to use FlatPak? That's a lot of changes... And are these two
> approaches compatible with the other platforms they target, or are
> they just likely to drop the one it stops working on?
>
> I can hardly imagine Teamviewer is the only 32-bit only GUI program.
There are all sorts of proprietary programs like Skype that are only
provided as 32-bit packages (there's a "skypeforlinux" package which
is 64-bit but it's an "alpha" release).
Maybe it would work fine from inside a 32-bit container, I have no
idea, but we should be careful not to make it harder for normal users
to install and use software distributed outside Fedora. And not make
it harder for ISVs to provide RPMs that work on Fedora with minimal
effort.
I feel like if this happens it will hasten the day when those of us
primarily working in EL-variant land have to consider a need for a new,
EL-forward, RPM-based open source "community" OS.
Fedora's role of breaking all sorts of things because $shinyNewParadigm
-- moving further and further from the semblance of stability available
in just being an extrapolation of where RHEL and its derivatives end up
-- does create certain operational borders. Eventually that friction
becomes unbearable.
-jc
6:08 p.m.
On Thu, Jan 5, 2017 at 2:40 PM, Japheth Cleaver <cleaver(a)terabithia.org> wrote:
I feel like if this happens it will hasten the day when those of us
primarily working in EL-variant land have to consider a need for a new,
EL-forward, RPM-based open source "community" OS.
Fedora's role of breaking all sorts of things because $shinyNewParadigm --
moving further and further from the semblance of stability available in just
being an extrapolation of where RHEL and its derivatives end up -- does
create certain operational borders. Eventually that friction becomes
unbearable.
Uhh, I see this as something is degrading and inevitably going to fall
apart. There's the spit and baling wire approach, where the ostrich
maneuver would mean at least we wouldn't have to witness the
aftermath. Or there's this other idea that Stephen had which sounded
to me like it's trying to leverage learned things, not invent all
shiny new stuff. It was a trial balloon anyway, so I wouldn't make it
out to be more than grandiose than that.
--
Chris Murphy
6:29 p.m.
On Thu, Jan 5, 2017 at 4:40 PM, Japheth Cleaver <cleaver(a)terabithia.org> wrote:
On 1/5/2017 9:12 AM, Jonathan Wakely wrote:
>
> On 05/01/17 09:56 -0700, Chris Murphy wrote:
>>
>> Teamviewer comes in an i686 only package for Fedora. So is there going
>> to be this interim approach, and then yet another change when they're
>> expected to use FlatPak? That's a lot of changes... And are these two
>> approaches compatible with the other platforms they target, or are
>> they just likely to drop the one it stops working on?
>>
>> I can hardly imagine Teamviewer is the only 32-bit only GUI program.
>
>
> There are all sorts of proprietary programs like Skype that are only
> provided as 32-bit packages (there's a "skypeforlinux" package which
> is 64-bit but it's an "alpha" release).
>
> Maybe it would work fine from inside a 32-bit container, I have no
> idea, but we should be careful not to make it harder for normal users
> to install and use software distributed outside Fedora. And not make
> it harder for ISVs to provide RPMs that work on Fedora with minimal
> effort.
I feel like if this happens it will hasten the day when those of us
primarily working in EL-variant land have to consider a need for a new,
EL-forward, RPM-based open source "community" OS.
Can you elaborate why you think that? Particularly the "EL-forward"
part. I don't understand how Stephen's line of thinking is not
EL-forward.
Fedora's role of breaking all sorts of things because
$shinyNewParadigm --
moving further and further from the semblance of stability available in just
being an extrapolation of where RHEL and its derivatives end up -- does
create certain operational borders. Eventually that friction becomes
unbearable.
If it's containers you are talking about, then I'm even more confused.
You're aware that containers are a very important part of the Red Hat
ecosystem today, right?
The value add of any enterprise distribution is to take
$shinyNewParadigm, nurture it upstream, focus on stability and
performance of the technologies in it's own offerings, and provide
support. Not having a vibrant community project where some of this
innovation can incubate is crippling any enterprise OS's ability to
remain flexible and relevant in the market place. The days of RHEL
being _only_ the thing you use on large datacenter servers are pretty
much already gone. It is that, and much more.
josh
9:34 a.m.
On 5 January 2017 at 19:29, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Thu, Jan 5, 2017 at 4:40 PM, Japheth Cleaver
<cleaver(a)terabithia.org> wrote:
> On 1/5/2017 9:12 AM, Jonathan Wakely wrote:
>>
>> On 05/01/17 09:56 -0700, Chris Murphy wrote:
>>>
>>> Teamviewer comes in an i686 only package for Fedora. So is there going
>>> to be this interim approach, and then yet another change when they're
>>> expected to use FlatPak? That's a lot of changes... And are these two
>>> approaches compatible with the other platforms they target, or are
>>> they just likely to drop the one it stops working on?
>>>
>>> I can hardly imagine Teamviewer is the only 32-bit only GUI program.
>>
>>
>> There are all sorts of proprietary programs like Skype that are only
>> provided as 32-bit packages (there's a "skypeforlinux" package
which
>> is 64-bit but it's an "alpha" release).
>>
>> Maybe it would work fine from inside a 32-bit container, I have no
>> idea, but we should be careful not to make it harder for normal users
>> to install and use software distributed outside Fedora. And not make
>> it harder for ISVs to provide RPMs that work on Fedora with minimal
>> effort.
>
>
> I feel like if this happens it will hasten the day when those of us
> primarily working in EL-variant land have to consider a need for a new,
> EL-forward, RPM-based open source "community" OS.
Can you elaborate why you think that? Particularly the "EL-forward"
part. I don't understand how Stephen's line of thinking is not
EL-forward.
I think it is because EL-forward means different things to different people.
1. Developer definition. EL-Forward is looking towards how something
will work in EL-next.
2. Enterprise operations. EL-Forward is looking towards how to take
something in current Fedora and move it forward to the version of
Enterprise you have deployed. [From a developer point of view it is
moving it backwards but it is because we are driving in two different
directions.]
A large amount of Enterprise ops people have to work in environments
with 30% of the systems being EL-5, 50% of the systems being EL-6 and
20% being EL-7. They have to both make corporate apps work with
ancient code bases but also get apps that need later items to make
things work. The work flow for this is
1. Find it in an 'approved' repo. [This was in the past EPEL but less
so due to aging items.]
2. Take the latest Fedora rpm and recompile/mangle the bits until it
works on EL5/EL6.
3. Get a bunch of tar-balls and make them work... but pay for the
upgrade problems later.
If they have problems in 2 or 1 they feed that back as bug reports and
considered that how they pushed Fedora forward. At some point they
would get to be able to install EL-8 and would have packages they knew
worked in Fedora from say Fedora-30 that would work for what they
needed.
Why does this not look forward to them?
1) They are still primarily having to deal with 32 bit applications.
2) They are only getting to virtualize their main environments. Yes
they have some systems somewhere in the giant bank IT that are
containered and that admin gets trotted out at docker con as the
forward way the world is working but 99% of the operations staff is
having to deal with an OS which is going to be EOL in 3 months and is
only now getting a budget which says they can move it to EL6. [They
can't move it to EL7 because the vendor still hasn't produced a
version of XYZ that 'works with systemd' (eg it relys on some initd
hack that they don't know how to fix to start up).]
3) Containers don't look baked yet. People are still arguing about how
to upgrade/update them.. the ones they google to see how it works of
them say they are read only but have instructions of 'install an ssh
and then log in and make these changes to really get it to work' etc
etc. Maybe Fedora will deliver all the packages in Fedora 27 with
docker formatting.. and maybe Fedora 28 will use a completely new
one..
4) The oracles they rely on to say this is how things are done in
Linux haven't agreed yet. The usual rule from previous technology
changes is don't bet on what the markets are using.. see what one
Linus uses for N months and if he doesn't like it see what he replaces
it with as that will be the way things go. [This is usually from
people who were burned deploying enterprise CVS, SVN, HG, BZR
solutions to have them all replaced with git in the last 5 years..
older admins have other Linus did it this way and everyone went that
way too.. the fact that Linus didn't have a tantrum and replace
systemd was pretty much the "ok it looks like this is the way things
are going"]
So if the OS they rely on to grab/build packages no longer offers a
way they can consume them (it has to be in a container which you will
need to run in your EL5/6 environment somehow..) then it can look like
the OS is no longer wanting EL to use it.
And it doesn't matter how much Red Hat says it is banking on
containers.. that is something that most of these Enterprise op people
aren't going to see for a decade.
--
Stephen J Smoogen.
10:17 a.m.
On 05/01/17 16:03, Stephen Gallagher wrote:
For many years, Fedora has supported multilib by carrying
parallel-installable
libraries in /usr/lib[64]. This was necessary for a very long time in order to
support 32-bit applications running on a 64-bit deployment. However, in today's
new container world, there is a whole new option.
You may be living in a "new container world" but that doesn't mean the
rest of us (or our users) are.
I'd like to propose that we consider moving away from our
traditional approach
to multilib in favor of recommending the use of a 32-bit container runtime when
needed on a 64-bit host.
On the face of it it sounds like a terrible idea but perhaps I have
misunderstood the consequences.
Can you explain what this would actually mean for an average software
developer trying to build a 32 bit program?
Take for example my day job where I'm developing a proprietary
application on a Fedora workstation. Now mostly I use a 64 bit build of
the software but we have a few databases we support where the vendor
doesn't provide 64 bit libraries so I have to use a 32 bit build.
Would this mean I had to do some special dance to enter a container
environment in order to work with a 32 bit build rather than just
telling our build scripts to use "gcc -m32" when compiling?
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
10:25 a.m.
On 01/05/2017 11:17 AM, Tom Hughes wrote:
On 05/01/17 16:03, Stephen Gallagher wrote:
> For many years, Fedora has supported multilib by carrying parallel-installable
> libraries in /usr/lib[64]. This was necessary for a very long time in order to
> support 32-bit applications running on a 64-bit deployment. However, in today's
> new container world, there is a whole new option.
You may be living in a "new container world" but that doesn't mean the rest
of
us (or our users) are.
By "new container world" I meant "a world where containers exist and can
offer a
complete 32-bit runtime" rather than a hacked-in multilib runtime.
> I'd like to propose that we consider moving away from our
traditional approach
> to multilib in favor of recommending the use of a 32-bit container runtime when
> needed on a 64-bit host.
On the face of it it sounds like a terrible idea but perhaps I have
misunderstood the consequences.
Can you explain what this would actually mean for an average software developer
trying to build a 32 bit program?
Take for example my day job where I'm developing a proprietary application on a
Fedora workstation. Now mostly I use a 64 bit build of the software but we have
a few databases we support where the vendor doesn't provide 64 bit libraries so
I have to use a 32 bit build.
Would this mean I had to do some special dance to enter a container environment
in order to work with a 32 bit build rather than just telling our build scripts
to use "gcc -m32" when compiling?
Building of software shouldn't be changed at all in most cases. The main
difference would be installation/deployment. The idea would be that instead of
the 32-bit and 64-bit runtimes being installed directly in parallel on the base
system, they would instead be installed into effectively a chroot with its own
completely 32-bit runtime.
In practical terms, this would be akin to installing it on a 32-bit VM, except
without the overhead and a separate kernel.
It gets a bit fuzzier when it has to interact with certain system services (see
the "Open Questions" for some examples).
10:41 a.m.
On 05/01/17 16:25, Stephen Gallagher wrote:
Building of software shouldn't be changed at all in most cases.
The main
difference would be installation/deployment. The idea would be that instead of
the 32-bit and 64-bit runtimes being installed directly in parallel on the base
system, they would instead be installed into effectively a chroot with its own
completely 32-bit runtime.
Right, but even if manages to compile and link (it somehow finds glibc
inside that chroot?) what happens if I run the program? Has the linker
automatically added a run path to it that points at the chroot so it can
find libc?
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
11:02 a.m.
On 05/01/17 11:25 -0500, Stephen Gallagher wrote:
On 01/05/2017 11:17 AM, Tom Hughes wrote:
> Would this mean I had to do some special dance to enter a container environment
> in order to work with a 32 bit build rather than just telling our build scripts
> to use "gcc -m32" when compiling?
>
Building of software shouldn't be changed at all in most cases.
I'm not sure how that's possible.
The main
difference would be installation/deployment. The idea would be that instead of
the 32-bit and 64-bit runtimes being installed directly in parallel on the base
system, they would instead be installed into effectively a chroot with its own
completely 32-bit runtime.
Which changes how software is built, surely.
Tom's use case is where you simply invoke "gcc -m32" on the base
system and (assuming the relevant 32-bit versions of the libs are
present in /usr/lib) it Just Works.
If the 32-bit headers and libs aren't present on the base system then
you have to change how the software is built.
In practical terms, this would be akin to installing it on a 32-bit
VM, except
without the overhead and a separate kernel.
Which definitely changes how software is built.
I'm sympathetic to the view that building in a pure-32-bit container
is probably ideologically better, but it's not how most of us are used
to working today. Building a 32-bit x86 application on an x86_64 host
is simple and doesn't involve containers.
Also, how would this work for something like GCC which wants to build
both 64-bit and 32-bit versions of runtime libraries, like libstdc++
and libgcc? If the base system doesn't have the 32-bit glibc libraries
present, how would GCC link the 32-bit libstdc++.so?
And as already mentioned, I don't know how this would affect Steam.
Please don't break Steam.
11:18 a.m.
On Jan 5, 2017 9:03 AM, "Jonathan Wakely" <jwakely(a)fedoraproject.org>
wrote:.
The main
difference would be installation/deployment. The idea would be that
instead of
the 32-bit and 64-bit runtimes being installed directly in parallel on the
base
system, they would instead be installed into effectively a chroot with its
own
completely 32-bit runtime.
Which changes how software is built, surely.
Tom's use case is where you simply invoke "gcc -m32" on the base
system and (assuming the relevant 32-bit versions of the libs are
present in /usr/lib) it Just Works.
If the 32-bit headers and libs aren't present on the base system then
you have to change how the software is built.
The Linux kernel needs gcc -m32 to work for freestanding programs.
Linux's x86 test suite likes normal glibc programs built with gcc -m32 to
work.
--Andy
1:42 p.m.
On Thu, 2017-01-05 at 17:02 +0000, Jonathan Wakely wrote:
Which definitely changes how software is built.
Containers also change the way software must be written in some cases,
since they expect there to be one main process and don't expect that
main process to interact with other "main" processes on the system.
There are some program architectures that aren't well suited to be run
in containers since containers expect programs to work in specific
ways. I don't think they are general enough to cover all use cases.
I also expect that users will not appreciate being forced to use
containers if they want to keep being able to do things they can do
today. Offering it to them as an option rather than the only solution
is probably a friendlier approach.
6:33 a.m.
On 05/01/17 14:42 -0500, Randy Barlow wrote:
On Thu, 2017-01-05 at 17:02 +0000, Jonathan Wakely wrote:
> Which definitely changes how software is built.
Containers also change the way software must be written in some cases,
since they expect there to be one main process and don't expect that
main process to interact with other "main" processes on the system.
There are some program architectures that aren't well suited to be run
in containers since containers expect programs to work in specific
ways. I don't think they are general enough to cover all use cases.
I also expect that users will not appreciate being forced to use
containers if they want to keep being able to do things they can do
today. Offering it to them as an option rather than the only solution
is probably a friendlier approach.
That would certainly be a problem if the proposal was to run each
32-bit application in its own container environment, but I think the
suggestion is to have a single 32-bit container used by all 32-bit
software. With that approach all the 32-bit software would be able to
interact with the rest of the 32-bit system, there wouldn't be
segregation between them.
But we would need to consider how a 32-bit application starts other
programs via things like xdg-open. Would you have to have a 32-bit
browser installed so that you could click on links in 32-bit
applications? Would xdg-utils have to be installed on the system
twice, once in the 64-bit host and once in the 32-bit container? And
install things like Firefox and image viewers twice?
6:48 a.m.
----- Original Message -----
On 05/01/17 14:42 -0500, Randy Barlow wrote:
>On Thu, 2017-01-05 at 17:02 +0000, Jonathan Wakely wrote:
>> Which definitely changes how software is built.
>
>Containers also change the way software must be written in some cases,
>since they expect there to be one main process and don't expect that
>main process to interact with other "main" processes on the system.
>There are some program architectures that aren't well suited to be run
>in containers since containers expect programs to work in specific
>ways. I don't think they are general enough to cover all use cases.
>
>I also expect that users will not appreciate being forced to use
>containers if they want to keep being able to do things they can do
>today. Offering it to them as an option rather than the only solution
>is probably a friendlier approach.
That would certainly be a problem if the proposal was to run each
32-bit application in its own container environment, but I think the
suggestion is to have a single 32-bit container used by all 32-bit
software. With that approach all the 32-bit software would be able to
interact with the rest of the 32-bit system, there wouldn't be
segregation between them.
But we would need to consider how a 32-bit application starts other
programs via things like xdg-open. Would you have to have a 32-bit
browser installed so that you could click on links in 32-bit
applications? Would xdg-utils have to be installed on the system
twice, once in the 64-bit host and once in the 32-bit container? And
install things like Firefox and image viewers twice?
I wonder how that would work when 1) you need access outside the sandbox
(say to play audio through PulseAudio, which needs an ALSA 32-bit plugin),
or 2) the 32-bit binary is a plugin (remember 32-bit Flash inside Firefox
with the nppluginwrapper?).
7:06 a.m.
On 01/06/2017 07:33 AM, Jonathan Wakely wrote:
On 05/01/17 14:42 -0500, Randy Barlow wrote:
> On Thu, 2017-01-05 at 17:02 +0000, Jonathan Wakely wrote:
>> Which definitely changes how software is built.
>
> Containers also change the way software must be written in some cases,
> since they expect there to be one main process and don't expect that
> main process to interact with other "main" processes on the system.
> There are some program architectures that aren't well suited to be run
> in containers since containers expect programs to work in specific
> ways. I don't think they are general enough to cover all use cases.
>
> I also expect that users will not appreciate being forced to use
> containers if they want to keep being able to do things they can do
> today. Offering it to them as an option rather than the only solution
> is probably a friendlier approach.
That would certainly be a problem if the proposal was to run each
32-bit application in its own container environment, but I think the
suggestion is to have a single 32-bit container used by all 32-bit
software. With that approach all the 32-bit software would be able to
interact with the rest of the 32-bit system, there wouldn't be
segregation between them.
Yes, I was unclear about this, but that was where I was going with it. A single
32-bit container whose purpose was to share the 32-bit runtime. That being said,
the counter-proposal of figuring out how to keep the layout the same as today
but keeping the content in separate repositories is compelling and I'm
investigating that further.
But we would need to consider how a 32-bit application starts other
programs via things like xdg-open. Would you have to have a 32-bit
browser installed so that you could click on links in 32-bit
applications? Would xdg-utils have to be installed on the system
twice, once in the 64-bit host and once in the 32-bit container? And
install things like Firefox and image viewers twice?
Very good questions and I don't have all the answers right now, but again, I
think the "separate repository" solution might be closer, as the end result
should keep things in the same hierarchy.
11:27 a.m.
On 01/05/2017 05:25 PM, Stephen Gallagher wrote:
Building of software shouldn't be changed at all in most cases.
The main
difference would be installation/deployment. The idea would be that instead of
the 32-bit and 64-bit runtimes being installed directly in parallel on the base
system, they would instead be installed into effectively a chroot with its own
completely 32-bit runtime.
Downstream doesn't provide these chroots for the 32-bit variants at
present, so I expect that most 32-bit build environments use the -m32
(or -m31) approach there. This is a very significant change. (Of
course, an even more significant change is just around the corner:
32-bit architectures are almost out of the picture anyway.)
Or you end up cross-compiling, with some path/sysroot hackery. Even if
the kernel could theoretically run the built binaries, all the userspace
libraries are still missing, so it would effectively be cross-compilation.
Thanks,
Florian
12:26 p.m.
On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 01/05/2017 11:17 AM, Tom Hughes wrote:
> On 05/01/17 16:03, Stephen Gallagher wrote:
>
>> For many years, Fedora has supported multilib by carrying parallel-installable
>> libraries in /usr/lib[64]. This was necessary for a very long time in order to
>> support 32-bit applications running on a 64-bit deployment. However, in
today's
>> new container world, there is a whole new option.
>
> You may be living in a "new container world" but that doesn't mean the
rest of
> us (or our users) are.
>
By "new container world" I meant "a world where containers exist and can
offer a
complete 32-bit runtime" rather than a hacked-in multilib runtime.
>> I'd like to propose that we consider moving away from our traditional
approach
>> to multilib in favor of recommending the use of a 32-bit container runtime when
>> needed on a 64-bit host.
>
> On the face of it it sounds like a terrible idea but perhaps I have
> misunderstood the consequences.
>
> Can you explain what this would actually mean for an average software developer
> trying to build a 32 bit program?
>
> Take for example my day job where I'm developing a proprietary application on a
> Fedora workstation. Now mostly I use a 64 bit build of the software but we have
> a few databases we support where the vendor doesn't provide 64 bit libraries so
> I have to use a 32 bit build.
>
> Would this mean I had to do some special dance to enter a container environment
> in order to work with a 32 bit build rather than just telling our build scripts
> to use "gcc -m32" when compiling?
>
Building of software shouldn't be changed at all in most cases. The main
difference would be installation/deployment. The idea would be that instead of
the 32-bit and 64-bit runtimes being installed directly in parallel on the base
system, they would instead be installed into effectively a chroot with its own
completely 32-bit runtime.
You just described a fundamental change to how people would need to
build 32-bit applications locally. They don't have to install a
VM/chroot to do that today, they would in a containerized multilib
solution. I don't think it's fair to claim "Building of software
shouldn't be changed at all in most cases" with this proposal.
Remember, not all software is built in mock or even as RPMs. End user
software developers will be impacted by the removal of existing
multilib.
josh
12:31 p.m.
On 01/05/2017 01:26 PM, Josh Boyer wrote:
On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher
<sgallagh(a)redhat.com> wrote:
> On 01/05/2017 11:17 AM, Tom Hughes wrote:
>> On 05/01/17 16:03, Stephen Gallagher wrote:
>>
>>> For many years, Fedora has supported multilib by carrying
parallel-installable
>>> libraries in /usr/lib[64]. This was necessary for a very long time in order
to
>>> support 32-bit applications running on a 64-bit deployment. However, in
today's
>>> new container world, there is a whole new option.
>> You may be living in a "new container world" but that doesn't mean
the rest of
>> us (or our users) are.
>>
> By "new container world" I meant "a world where containers exist and
can offer a
> complete 32-bit runtime" rather than a hacked-in multilib runtime.
>
>>> I'd like to propose that we consider moving away from our traditional
approach
>>> to multilib in favor of recommending the use of a 32-bit container runtime
when
>>> needed on a 64-bit host.
>> On the face of it it sounds like a terrible idea but perhaps I have
>> misunderstood the consequences.
>>
>> Can you explain what this would actually mean for an average software developer
>> trying to build a 32 bit program?
>>
>> Take for example my day job where I'm developing a proprietary application on
a
>> Fedora workstation. Now mostly I use a 64 bit build of the software but we have
>> a few databases we support where the vendor doesn't provide 64 bit libraries
so
>> I have to use a 32 bit build.
>>
>> Would this mean I had to do some special dance to enter a container environment
>> in order to work with a 32 bit build rather than just telling our build scripts
>> to use "gcc -m32" when compiling?
>>
> Building of software shouldn't be changed at all in most cases. The main
> difference would be installation/deployment. The idea would be that instead of
> the 32-bit and 64-bit runtimes being installed directly in parallel on the base
> system, they would instead be installed into effectively a chroot with its own
> completely 32-bit runtime.
You just described a fundamental change to how people would need to
build 32-bit applications locally. They don't have to install a
VM/chroot to do that today, they would in a containerized multilib
solution. I don't think it's fair to claim "Building of software
shouldn't be changed at all in most cases" with this proposal.
Remember, not all software is built in mock or even as RPMs. End user
software developers will be impacted by the removal of existing
multilib.
josh
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Sadly will we
be hearing these same arguments 10 years from now...
12:36 p.m.
On 5 January 2017 at 13:31, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>> You just described a fundamental change to how people would need to
>> build 32-bit applications locally. They don't have to install a
>> VM/chroot to do that today, they would in a containerized multilib
>> solution. I don't think it's fair to claim "Building of software
>> shouldn't be changed at all in most cases" with this proposal.
> >> Remember, not all software is built in mock or even as
RPMs. End user
>> software developers will be impacted by the removal of existing
>> multilib.
> >> josh
Sadly will we be hearing these same arguments 10 years from now...
Yes. We will. And in 10 years from now the inevitable backlash against
containers because they aren't new and nifty and had all these warts
that come from real life will be in full swing. [This doesn't mean
that containers will go away any more than they were completely new in
the first place but ideas that Multics (and other OS's had) in the
1960/70's.] This is how software goes.
--
Stephen J Smoogen.
12:48 p.m.
On 01/05/2017 01:36 PM, Stephen John Smoogen wrote:
On 5 January 2017 at 13:31, Daniel J Walsh <dwalsh(a)redhat.com>
wrote:
>> You just described a fundamental change to how people would need to
>> build 32-bit applications locally. They don't have to install a
>> VM/chroot to do that today, they would in a containerized multilib
>> solution. I don't think it's fair to claim "Building of software
>> shouldn't be changed at all in most cases" with this proposal.
>>
>> Remember, not all software is built in mock or even as RPMs. End user
>> software developers will be impacted by the removal of existing
>> multilib.
>>
>> josh
> Sadly will we be hearing these same arguments 10 years from now...
Yes. We will. And in 10 years from now the inevitable backlash against
containers because they aren't new and nifty and had all these warts
that come from real life will be in full swing. [This doesn't mean
that containers will go away any more than they were completely new in
the first place but ideas that Multics (and other OS's had) in the
1960/70's.] This is how software goes.
Well we will be retired at that point, and playing shuffle board.
1:11 p.m.
On Thu, Jan 5, 2017 at 10:50 AM Daniel J Walsh <dwalsh(a)redhat.com> wrote:
Well we will be retired at that point, and playing shuffle board.
Well, I'm retired *now* and I'm still a Fedora end-user. ;-)
But seriously ... aren't there plenty of distros that support older 32-bit
hardware ... enough so that Fedora can draw a line in the sand and say,
Fedora 27 will be ARM and 64-bit x86 only? Let Debian support all the other
stuff and run it in a Debian container?
And speaking of Wine, how come the Windows 10 Linux subsystem only runs
Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows machine?
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
How many people can stand on the shoulders of a giant before the giant
collapses?
1:15 p.m.
On Thu, Jan 5, 2017 at 2:11 PM, M. Edward (Ed) Borasky <znmeb(a)znmeb.net> wrote:
On Thu, Jan 5, 2017 at 10:50 AM Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>
> Well we will be retired at that point, and playing shuffle board.
Well, I'm retired *now* and I'm still a Fedora end-user. ;-)
But seriously ... aren't there plenty of distros that support older 32-bit
hardware ... enough so that Fedora can draw a line in the sand and say,
Fedora 27 will be ARM and 64-bit x86 only? Let Debian support all the other
stuff and run it in a Debian container?
Um... no. Why would we drop the other alternative architectures that
have worked diligently to release in lock-step with x86_64? I have a
fundamental disagreement with that suggestion.
And speaking of Wine, how come the Windows 10 Linux subsystem only
runs
Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows machine?
I think you should start another thread about that topic.
josh
1:30 p.m.
Once upon a time, M. Edward (Ed) Borasky <znmeb(a)znmeb.net> said:
But seriously ... aren't there plenty of distros that support
older 32-bit
hardware ... enough so that Fedora can draw a line in the sand and say,
Fedora 27 will be ARM and 64-bit x86 only? Let Debian support all the other
stuff and run it in a Debian container?
If I have to run Debian to use the software I need/want (for example, as
others already mentioned in this thread, I use Teamviewer and Steam),
then I'm not going to run Fedora as well.
It isn't about 32-bit hardware, it is about 32-bit software. I'd love
to be running a pure open source system, but in the real world, I can't.
--
Chris Adams <linux(a)cmadams.net>
3:01 a.m.
New subject: Fedora Linux subsystem on Windows machine
Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
And speaking of Wine, how come the Windows 10 Linux subsystem only
runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows
machine?
Just FYI:
http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora
Vít
3:03 a.m.
New subject: Fedora Linux subsystem on Windows machine
On Fri, 06 Jan 2017 10:01:01 +0100, Vít Ondruch <vondruch(a)redhat.com>
wrote:
Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
>
>
>
>
> And speaking of Wine, how come the Windows 10 Linux subsystem only
> runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows
> machine?
Just FYI:
http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora
Vít
I think that doesn't work anymore. But there's this project that should
work now [0], while being more user friendly and versatile.
[0] https://github.com/RoliSoft/WSL-Distribution-Switcher
3:46 a.m.
New subject: Fedora Linux subsystem on Windows machine
Dne 6.1.2017 v 10:03 Martin Bříza napsal(a):
On Fri, 06 Jan 2017 10:01:01 +0100, Vít Ondruch
<vondruch(a)redhat.com>
wrote:
>
>
> Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
>>
>>
>>
>>
>> And speaking of Wine, how come the Windows 10 Linux subsystem only
>> runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows
>> machine?
>
> Just FYI:
>
>
> http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora
>
>
> Vít
I think that doesn't work anymore. But there's this project that
should work now [0], while being more user friendly and versatile.
[0] https://github.com/RoliSoft/WSL-Distribution-Switcher
Thanks for pointing this out. I knew I saw something more advanced, but
already forgot what it was ;) I am not windows user mysefl ...
Vít
2:35 p.m.
New subject: Fedora Linux subsystem on Windows machine
Nice!!
On Fri, Jan 6, 2017 at 1:47 AM Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 6.1.2017 v 10:03 Martin Bříza napsal(a):
> On Fri, 06 Jan 2017 10:01:01 +0100, Vít Ondruch <vondruch(a)redhat.com>
> wrote:
>
>>
>>
>> Dne 5.1.2017 v 20:11 M. Edward (Ed) Borasky napsal(a):
>>>
>>>
>>>
>>>
>>> And speaking of Wine, how come the Windows 10 Linux subsystem only
>>> runs Ubuntu? Why can't I run a Fedora Linux subsystem on my Windows
>>> machine?
>>
>> Just FYI:
>>
>>
>> http://stackoverflow.com/questions/38802362/windows-10-wsl-with-fedora
>>
>>
>> Vít
>
> I think that doesn't work anymore. But there's this project that
> should work now [0], while being more user friendly and versatile.
>
> [0] https://github.com/RoliSoft/WSL-Distribution-Switcher
Thanks for pointing this out. I knew I saw something more advanced, but
already forgot what it was ;) I am not windows user mysefl ...
Vít
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
How many people can stand on the shoulders of a giant before the giant
collapses?
12:40 p.m.
On Thu, Jan 5, 2017 at 1:31 PM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
On 01/05/2017 01:26 PM, Josh Boyer wrote:
> On Thu, Jan 5, 2017 at 11:25 AM, Stephen Gallagher <sgallagh(a)redhat.com>
wrote:
>> On 01/05/2017 11:17 AM, Tom Hughes wrote:
>>> On 05/01/17 16:03, Stephen Gallagher wrote:
>>>
>>>> For many years, Fedora has supported multilib by carrying
parallel-installable
>>>> libraries in /usr/lib[64]. This was necessary for a very long time in
order to
>>>> support 32-bit applications running on a 64-bit deployment. However, in
today's
>>>> new container world, there is a whole new option.
>>> You may be living in a "new container world" but that doesn't
mean the rest of
>>> us (or our users) are.
>>>
>> By "new container world" I meant "a world where containers exist
and can offer a
>> complete 32-bit runtime" rather than a hacked-in multilib runtime.
>>
>>>> I'd like to propose that we consider moving away from our traditional
approach
>>>> to multilib in favor of recommending the use of a 32-bit container
runtime when
>>>> needed on a 64-bit host.
>>> On the face of it it sounds like a terrible idea but perhaps I have
>>> misunderstood the consequences.
>>>
>>> Can you explain what this would actually mean for an average software
developer
>>> trying to build a 32 bit program?
>>>
>>> Take for example my day job where I'm developing a proprietary
application on a
>>> Fedora workstation. Now mostly I use a 64 bit build of the software but we
have
>>> a few databases we support where the vendor doesn't provide 64 bit
libraries so
>>> I have to use a 32 bit build.
>>>
>>> Would this mean I had to do some special dance to enter a container
environment
>>> in order to work with a 32 bit build rather than just telling our build
scripts
>>> to use "gcc -m32" when compiling?
>>>
>> Building of software shouldn't be changed at all in most cases. The main
>> difference would be installation/deployment. The idea would be that instead of
>> the 32-bit and 64-bit runtimes being installed directly in parallel on the base
>> system, they would instead be installed into effectively a chroot with its own
>> completely 32-bit runtime.
> You just described a fundamental change to how people would need to
> build 32-bit applications locally. They don't have to install a
> VM/chroot to do that today, they would in a containerized multilib
> solution. I don't think it's fair to claim "Building of software
> shouldn't be changed at all in most cases" with this proposal.
>
> Remember, not all software is built in mock or even as RPMs. End user
> software developers will be impacted by the removal of existing
> multilib.
Sadly will we be hearing these same arguments 10 years from now...
I'm not suggesting we shouldn't change our multilib strategy. I'm
saying we can't change it can claim that it won't impact end users.
That is all.
josh
5 p.m.
On Thu, Jan 05, 2017 at 01:31:19PM -0500, Daniel J Walsh wrote:
Sadly will we be hearing these same arguments 10 years from now...
A 10 year horizon is also the timeframe proposed for introducing
RISC-V 128 bit hardware (128 bit emulation is already available,
although unless you enjoy writing machine code by hand it's not much
use right now), so we'll have potentially 3 different arches to
target.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
10:26 a.m.
On Thu, Jan 05, 2017 at 11:03:50AM -0500, Stephen Gallagher wrote:
* Do we need to care about 32-bit GUI applications on a 64-bit
system? Should we
decide that flatpak is the official answer for such cases?
The main thing that comes to mind is Wine. Perhaps PlayOnLinux
could be made into a Flatpak?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:28 a.m.
While most desktop applications have migrated to 64 bit at this point there are
still many that hasn't. Steam for instance is still 32-bit afaict. So doing a clean
cutover like this feel a bit to drastic to me and I am not sure we have the market power
to 'force' vendors to quickly migrate to containers.
Christian
----- Original Message -----
> From: "Stephen Gallagher" <sgallagh(a)redhat.com>
> To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
> Sent: Thursday, January 5, 2017 11:03:50 AM
> Subject: Proposal: Rethink Fedora multilib support
>
> # Overview
>
> For many years, Fedora has supported multilib by carrying
> parallel-installable
> libraries in /usr/lib[64]. This was necessary for a very long time in order
> to
> support 32-bit applications running on a 64-bit deployment. However, in
> today's
> new container world, there is a whole new option.
>
> I'd like to propose that we consider moving away from our traditional
> approach
> to multilib in favor of recommending the use of a 32-bit container runtime
> when
> needed on a 64-bit host.
>
>
> ## Advantages
>
> * Simplification of build-tree creation. We wouldn't have to maintain the
> lists
> and hacks that are required to make sure that multilib packages land in the
> correct repositories.
>
> * Less duplication of content in the mirror networks.
>
> * It will be simpler to create module content without having to reimplement
> all
> the multilib hacks of above. This is directly relevant to the Base Runtime
> module, whose prototype is today intentionally limited to the primary
> architecture (no multilib).
>
> * Requires us to maintain and keep up-to-date the 32-bit container base
> images.
>
>
> ## Disadvantages
>
> * If we eliminate multilib entirely, all applications that use 32-bit libs
> will
> have to either install a 32-bit host OS or install into a container. This may
> be
> a difficult transition for some users.
> * Mitigation: develop and maintain tools to ease this transition.
>
> * It is unlikely that any clean upgrade path would exist. (We could make it
> *technically* possible, but likely not without breaking 32-bit software not
> installed by RPM.
>
> * Requires us to maintain and keep up-to-date the 32-bit container base
> images.
> (Yes, this is both an advantage and disadvantage.)
>
>
> ## Open Questions (non-exhaustive):
>
> * Can SSSD and systemd's 32-bit name-service modules work from within a
> container, talking to their host's service? Without that, 32-bit containers
> won't be able to resolve users, groups or hostnames.
>
> * Can we have 32-bit containers communicate with other local system APIs such
> as
> D-BUS on the host?
>
> * Do we need to care about 32-bit GUI applications on a 64-bit system? Should
> we
> decide that flatpak is the official answer for such cases?
>
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>
12:11 p.m.
On Thu, Jan 5, 2017 at 11:28 AM, Christian Schaller <cschalle(a)redhat.com>
wrote:
While most desktop applications have migrated to 64 bit at this
point
there are
still many that hasn't. Steam for instance is still 32-bit afaict. So
doing a clean
cutover like this feel a bit to drastic to me and I am not sure we have
the market power
to 'force' vendors to quickly migrate to containers.
Christian
I would go further and say that I'm almost certain Fedora does not have the
market power to accomplish this at the moment. Perhaps we could
*eventually* get major software vendors to migrate to containers but I'm
pretty sure there would be a period where at least some major proprietary
desktop applications are broken.
Speaking from an end-user perspective, I actually really like the way
multilib on Fedora is currently implemented. All I need to do to get a
32-bit application-- be it some Windows application under wine, some
proprietary application like Steam, etc.-- to work is to install the 32-bit
packages via yum/dnf, and then things Just Work.
I understand that from a building-the-distribution perspective the way this
is done currently is kind of a hack, but I can't help but notice that the
*only* benefits to this proposal would be that it makes building the
distribution easier. There are no proposed benefits for our users beyond
breaking the way things currently work with probably no upgrade path. And
whether we like it or not, users, myself included, install nonfree software
like Steam on systems and generally expect it to continue working from
release to release.
Ben Rosser
10:38 a.m.
Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
[...]
## Advantages
* Simplification of build-tree creation. We wouldn't have to maintain the lists
and hacks that are required to make sure that multilib packages land in the
correct repositories.
[...]
Just wondering: Why don't we switch to a multilib/multiarch solution
similar to the one that Debian/Ubuntu uses? They put libs in directories
like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
(https://wiki.debian.org/Multiarch/Implementation
https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
solution a new (de facto) standard might evolve and in the end nobody
would have to deal with hacks any more, because all major distros would
put libs in the same directories. Iirc their model has benefits for
cross-compilation, too.
Cu, knurd
10:42 a.m.
On 05/01/17 16:38, Thorsten Leemhuis wrote:
Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
> [...]
> ## Advantages
>
> * Simplification of build-tree creation. We wouldn't have to maintain the lists
> and hacks that are required to make sure that multilib packages land in the
> correct repositories.
> [...]
Just wondering: Why don't we switch to a multilib/multiarch solution
similar to the one that Debian/Ubuntu uses? They put libs in directories
like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
(https://wiki.debian.org/Multiarch/Implementation
https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
solution a new (de facto) standard might evolve and in the end nobody
would have to deal with hacks any more, because all major distros would
put libs in the same directories. Iirc their model has benefits for
cross-compilation, too.
That's exactly what I thought was about to be proposed when I saw the
subject of the email and I got excited for about 30 seconds until I read
the body ;-)
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
10:52 a.m.
On Thu, 5 Jan 2017 16:42:25 +0000
Tom Hughes <tom(a)compton.nu> wrote:
On 05/01/17 16:38, Thorsten Leemhuis wrote:
> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
>> [...]
>> ## Advantages
>>
>> * Simplification of build-tree creation. We wouldn't have to
>> maintain the lists and hacks that are required to make sure that
>> multilib packages land in the correct repositories.
>> [...]
>
> Just wondering: Why don't we switch to a multilib/multiarch solution
> similar to the one that Debian/Ubuntu uses? They put libs in
> directories like /usr/lib/i386-linux-gnu
> and /usr/lib/x86_64-linux-gnu
> (https://wiki.debian.org/Multiarch/Implementation
> https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a
> similar solution a new (de facto) standard might evolve and in the
> end nobody would have to deal with hacks any more, because all
> major distros would put libs in the same directories. Iirc their
> model has benefits for cross-compilation, too.
That's exactly what I thought was about to be proposed when I saw the
subject of the email and I got excited for about 30 seconds until I
read the body ;-)
couldn't you add on a pure 64-bit system a pure 32-bit repo (with lower
priority) and wouldn't things still work?
Dan
10:56 a.m.
On 01/05/2017 11:42 AM, Tom Hughes wrote:
On 05/01/17 16:38, Thorsten Leemhuis wrote:
> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
>> [...]
>> ## Advantages
>>
>> * Simplification of build-tree creation. We wouldn't have to maintain the
lists
>> and hacks that are required to make sure that multilib packages land in the
>> correct repositories.
>> [...]
>
> Just wondering: Why don't we switch to a multilib/multiarch solution
> similar to the one that Debian/Ubuntu uses? They put libs in directories
> like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
> (https://wiki.debian.org/Multiarch/Implementation
> https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
> solution a new (de facto) standard might evolve and in the end nobody
> would have to deal with hacks any more, because all major distros would
> put libs in the same directories. Iirc their model has benefits for
> cross-compilation, too.
That's exactly what I thought was about to be proposed when I saw the subject of
the email and I got excited for about 30 seconds until I read the body ;-)
If we end up staying with a multilib approach, there's certainly a lot of merit
to developing a cross-distribution standard.
However, it still doesn't solve the problem that we have today, which is that we
have to do a lot of hacky shuffling around of packages in order to take packages
built in i686 and drop them onto the x86_64 repository.
It might be different if we could build 32-bit sub-packages in the 64-bit mock
environment, but the tools are *really* not equipped to handle that today (in
particular because Fedora doesn't do cross-compilation; we just spin up a
builder of the actual hardware it should run on.)
11:05 a.m.
On Thu, Jan 05, 2017 at 11:56:28AM -0500, Stephen Gallagher wrote:
It might be different if we could build 32-bit sub-packages in the 64-bit mock
environment, but the tools are *really* not equipped to handle that today (in
particular because Fedora doesn't do cross-compilation; we just spin up a
builder of the actual hardware it should run on.)
NB, Fedora does do cross-compilation in some places - many of the QEMU
firmware blobs are cross-compiled, as is the Mingw32/64 toolchain.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
12:51 p.m.
Stephen Gallagher wrote:
However, it still doesn't solve the problem that we have today,
which is
that we have to do a lot of hacky shuffling around of packages in order to
take packages built in i686 and drop them onto the x86_64 repository.
Then just have the users enable the 32-bit repository if they want 32-bit
packages. IMHO, that would make sense.
Forcing everybody who needs multilib to use containers, on the other hand,
is a very bad idea.
Kevin Kofler
4:53 p.m.
On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote:
Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
> [...]
> ## Advantages
>
> * Simplification of build-tree creation. We wouldn't have to maintain the lists
> and hacks that are required to make sure that multilib packages land in the
> correct repositories.
> [...]
Just wondering: Why don't we switch to a multilib/multiarch solution
similar to the one that Debian/Ubuntu uses? They put libs in directories
like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
(https://wiki.debian.org/Multiarch/Implementation
https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
solution a new (de facto) standard might evolve and in the end nobody
would have to deal with hacks any more, because all major distros would
put libs in the same directories. Iirc their model has benefits for
cross-compilation, too.
IMHO this is a much better idea. Also being closer to Debian means
less hacking required to build GCC (or at least, it's the same hacking
as Debian needs). Also we can kill /usr/lib64 finally.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
4:55 p.m.
On Sat, Jan 7, 2017 at 5:53 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote:
> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
> > [...]
> > ## Advantages
> >
> > * Simplification of build-tree creation. We wouldn't have to maintain the
lists
> > and hacks that are required to make sure that multilib packages land in the
> > correct repositories.
> > [...]
>
> Just wondering: Why don't we switch to a multilib/multiarch solution
> similar to the one that Debian/Ubuntu uses? They put libs in directories
> like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
> (https://wiki.debian.org/Multiarch/Implementation
> https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
> solution a new (de facto) standard might evolve and in the end nobody
> would have to deal with hacks any more, because all major distros would
> put libs in the same directories. Iirc their model has benefits for
> cross-compilation, too.
IMHO this is a much better idea. Also being closer to Debian means
less hacking required to build GCC (or at least, it's the same hacking
as Debian needs). Also we can kill /usr/lib64 finally.
It improves the situation, but /usr/lib64 will be with us for a long
time to come...
--
真実はいつも一つ！/ Always, there's only one truth!
8:25 a.m.
On 07/01/17 22:53 +0000, Richard W.M. Jones wrote:
On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote:
> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
> > [...]
> > ## Advantages
> >
> > * Simplification of build-tree creation. We wouldn't have to maintain the
lists
> > and hacks that are required to make sure that multilib packages land in the
> > correct repositories.
> > [...]
>
> Just wondering: Why don't we switch to a multilib/multiarch solution
> similar to the one that Debian/Ubuntu uses? They put libs in directories
> like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
> (https://wiki.debian.org/Multiarch/Implementation
> https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
> solution a new (de facto) standard might evolve and in the end nobody
> would have to deal with hacks any more, because all major distros would
> put libs in the same directories. Iirc their model has benefits for
> cross-compilation, too.
IMHO this is a much better idea. Also being closer to Debian means
less hacking required to build GCC (or at least, it's the same hacking
as Debian needs).
How's that? To build GCC on Debian needs an entire new configure
option that isn't needed at all on Fedora: --enable-multiarch
There's *more* hacking needed to build GCC on Debian. So yes, if we
copy them we'll need the same hacking as Debian needs, but that's not
less hacking than we have now.
10:19 a.m.
Dne 11.1.2017 v 15:25 Jonathan Wakely napsal(a):
On 07/01/17 22:53 +0000, Richard W.M. Jones wrote:
> On Thu, Jan 05, 2017 at 05:38:58PM +0100, Thorsten Leemhuis wrote:
>> Lo! On 05.01.2017 17:03, Stephen Gallagher wrote:
>> > [...]
>> > ## Advantages
>> >
>> > * Simplification of build-tree creation. We wouldn't have to
>> maintain the lists
>> > and hacks that are required to make sure that multilib packages
>> land in the
>> > correct repositories.
>> > [...]
>>
>> Just wondering: Why don't we switch to a multilib/multiarch solution
>> similar to the one that Debian/Ubuntu uses? They put libs in
>> directories
>> like /usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu
>> (https://wiki.debian.org/Multiarch/Implementation
>> https://wiki.ubuntu.com/MultiarchSpec ). If we'd switch to a similar
>> solution a new (de facto) standard might evolve and in the end nobody
>> would have to deal with hacks any more, because all major distros would
>> put libs in the same directories. Iirc their model has benefits for
>> cross-compilation, too.
>
> IMHO this is a much better idea. Also being closer to Debian means
> less hacking required to build GCC (or at least, it's the same hacking
> as Debian needs).
How's that? To build GCC on Debian needs an entire new configure
option that isn't needed at all on Fedora: --enable-multiarch
There's *more* hacking needed to build GCC on Debian. So yes, if we
copy them we'll need the same hacking as Debian needs, but that's not
less hacking than we have now.
And yet the configuration is wrong and does not support the current
needs of packages on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=979403
Vít
11:09 a.m.
On Thu, Jan 05, 2017 at 11:03:50AM -0500, Stephen Gallagher wrote:
# Overview
For many years, Fedora has supported multilib by carrying parallel-installable
libraries in /usr/lib[64]. This was necessary for a very long time in order to
support 32-bit applications running on a 64-bit deployment. However, in today's
new container world, there is a whole new option.
I'd like to propose that we consider moving away from our traditional approach
to multilib in favor of recommending the use of a 32-bit container runtime when
needed on a 64-bit host.
## Advantages
* Simplification of build-tree creation. We wouldn't have to maintain the lists
and hacks that are required to make sure that multilib packages land in the
correct repositories.
* Less duplication of content in the mirror networks.
* It will be simpler to create module content without having to reimplement all
the multilib hacks of above. This is directly relevant to the Base Runtime
module, whose prototype is today intentionally limited to the primary
architecture (no multilib).
* Requires us to maintain and keep up-to-date the 32-bit container base images.
## Disadvantages
* If we eliminate multilib entirely, all applications that use 32-bit libs will
have to either install a 32-bit host OS or install into a container. This may be
a difficult transition for some users.
* Mitigation: develop and maintain tools to ease this transition.
* It is unlikely that any clean upgrade path would exist. (We could make it
*technically* possible, but likely not without breaking 32-bit software not
installed by RPM.
* Requires us to maintain and keep up-to-date the 32-bit container base images.
(Yes, this is both an advantage and disadvantage.)
More work for the end user to keep their systems updated. Containers in
general are a retrograde step in this area, since instead of being able
todo a simple "dnf update" on the host and have everything updated, you
have to do "dnf update" and then figure out how to update each individual
container. Even if we assume the 32-bit container base image lets you use
dnf normally, this change has at least added an extra step for users
as they have to upgrade their 64-bit and 32-bit container via separate
"dnf update" command invokations.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
11:20 a.m.
On Thu, Jan 05, 2017 at 05:09:59PM +0000, Daniel P. Berrange wrote:
More work for the end user to keep their systems updated. Containers
in
general are a retrograde step in this area, since instead of being able
todo a simple "dnf update" on the host and have everything updated, you
have to do "dnf update" and then figure out how to update each individual
container. Even if we assume the 32-bit container base image lets you use
dnf normally, this change has at least added an extra step for users
as they have to upgrade their 64-bit and 32-bit container via separate
"dnf update" command invokations.
Regards,
Daniel
I think we're only considering this for the modular composes,
where containers would be just instance of modules, managed
by the base system, presumably through something as simple as
"dnf update".
Plenty of assumptions but I believe that's the plan.
P
11:58 a.m.
On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher wrote:
# Overview
For many years, Fedora has supported multilib by carrying
parallel-installable libraries in /usr/lib[64]. This was necessary for a
very long time in order to support 32-bit applications running on a 64-bit
deployment. However, in today's new container world, there is a whole new
option.
I'd like to propose that we consider moving away from our traditional
approach to multilib in favor of recommending the use of a 32-bit container
runtime when needed on a 64-bit host.
I am not opposed, however I think we should
possibly just have people enable
the 32 bit x86 repo instead of your proposal
## Advantages
* Simplification of build-tree creation. We wouldn't have to maintain the
lists and hacks that are required to make sure that multilib packages land
in the correct repositories.
* Less duplication of content in the mirror networks.
the content is hardlinked so
this is not an issue
* It will be simpler to create module content without having to
reimplement
all the multilib hacks of above. This is directly relevant to the Base
Runtime module, whose prototype is today intentionally limited to the
primary architecture (no multilib).
Nothing stops us supporting multilib as we do
today, and not supporting in it
in modules
* Requires us to maintain and keep up-to-date the 32-bit container
base
images.
We have never made 32 bit containers, so this would be a entirely new
deliverable.
## Disadvantages
* If we eliminate multilib entirely, all applications that use 32-bit libs
will have to either install a 32-bit host OS or install into a container.
This may be a difficult transition for some users.
gcc would need to be
reconfigured to not be able to build 32 bit binaries on
64 bit
* Mitigation: develop and maintain tools to ease this transition.
* It is unlikely that any clean upgrade path would exist. (We could make it
*technically* possible, but likely not without breaking 32-bit software not
installed by RPM.
* Requires us to maintain and keep up-to-date the 32-bit container base
images. (Yes, this is both an advantage and disadvantage.)
given that i686 has been
demoted this is a bigger issue. than it would heva
been otherwise. How will apps like skype wine etc work that need to connect to
X?
## Open Questions (non-exhaustive):
* Can SSSD and systemd's 32-bit name-service modules work from within a
container, talking to their host's service? Without that, 32-bit containers
won't be able to resolve users, groups or hostnames.
* Can we have 32-bit containers communicate with other local system APIs
such as D-BUS on the host?
* Do we need to care about 32-bit GUI applications on a 64-bit system?
Should we decide that flatpak is the official answer for such cases?
Dennis
12:35 p.m.
On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher
wrote:
> # Overview
>
> For many years, Fedora has supported multilib by carrying
> parallel-installable libraries in /usr/lib[64]. This was necessary for a
> very long time in order to support 32-bit applications running on a 64-bit
> deployment. However, in today's new container world, there is a whole new
> option.
>
> I'd like to propose that we consider moving away from our traditional
> approach to multilib in favor of recommending the use of a 32-bit container
> runtime when needed on a 64-bit host.
I am not opposed, however I think we should possibly just have people enable
the 32 bit x86 repo instead of your proposal
Multilib exists on non-x86 architectures. Should this proposal gain
traction, we need to consider the implications to those architectures.
josh
12:42 p.m.
On jueves, 5 de enero de 2017 1:35:28 PM CST Josh Boyer wrote:
On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore
<dennis(a)ausil.us> wrote:
> On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher wrote:
>> # Overview
>>
>> For many years, Fedora has supported multilib by carrying
>> parallel-installable libraries in /usr/lib[64]. This was necessary for a
>> very long time in order to support 32-bit applications running on a
>> 64-bit
>> deployment. However, in today's new container world, there is a whole new
>> option.
>>
>> I'd like to propose that we consider moving away from our traditional
>> approach to multilib in favor of recommending the use of a 32-bit
>> container
>> runtime when needed on a 64-bit host.
>
> I am not opposed, however I think we should possibly just have people
> enable the 32 bit x86 repo instead of your proposal
Multilib exists on non-x86 architectures. Should this proposal gain
traction, we need to consider the implications to those architectures.
its been
killed off on all other arches.
Dennis
12:59 p.m.
On Thu, Jan 5, 2017 at 1:42 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
On jueves, 5 de enero de 2017 1:35:28 PM CST Josh Boyer wrote:
> On Thu, Jan 5, 2017 at 12:58 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
> > On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher wrote:
> >> # Overview
> >>
> >> For many years, Fedora has supported multilib by carrying
> >> parallel-installable libraries in /usr/lib[64]. This was necessary for a
> >> very long time in order to support 32-bit applications running on a
> >> 64-bit
> >> deployment. However, in today's new container world, there is a whole
new
> >> option.
> >>
> >> I'd like to propose that we consider moving away from our traditional
> >> approach to multilib in favor of recommending the use of a 32-bit
> >> container
> >> runtime when needed on a 64-bit host.
> >
> > I am not opposed, however I think we should possibly just have people
> > enable the 32 bit x86 repo instead of your proposal
>
> Multilib exists on non-x86 architectures. Should this proposal gain
> traction, we need to consider the implications to those architectures.
its been killed off on all other arches.
I stand corrected. For some reason I thought it still existed on
ppc64, but that is clearly not the case.
josh
12:55 p.m.
On Thu, 05 Jan 2017 11:58:06 -0600
Dennis Gilmore <dennis(a)ausil.us> wrote:
On jueves, 5 de enero de 2017 11:03:50 AM CST Stephen Gallagher
wrote:
> # Overview
>
> For many years, Fedora has supported multilib by carrying
> parallel-installable libraries in /usr/lib[64]. This was necessary
> for a very long time in order to support 32-bit applications
> running on a 64-bit deployment. However, in today's new container
> world, there is a whole new option.
>
> I'd like to propose that we consider moving away from our
> traditional approach to multilib in favor of recommending the use
> of a 32-bit container runtime when needed on a 64-bit host.
I am not opposed, however I think we should possibly just have people
enable the 32 bit x86 repo instead of your proposal
exactly, such solution should deliver the same user experience
Dan
2:44 p.m.
On 01/05/2017 08:03 AM, Stephen Gallagher wrote:
## Disadvantages
* If we eliminate multilib entirely, all applications that use 32-bit libs will
have to either install a 32-bit host OS or install into a container. This may be
a difficult transition for some users.
* Mitigation: develop and maintain tools to ease this transition.
* It is unlikely that any clean upgrade path would exist. (We could make it
*technically* possible, but likely not without breaking 32-bit software not
installed by RPM.
All of my 32-bit software is installed in $HOME/.local/share/Steam, I
take it that under this proposal it would immediately stop working upon
upgrading Fedora and never work again?
3:08 p.m.
On Thu, Jan 5, 2017 at 11:03 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
# Overview
For many years, Fedora has supported multilib by carrying parallel-installable
libraries in /usr/lib[64]. This was necessary for a very long time in order to
support 32-bit applications running on a 64-bit deployment. However, in today's
new container world, there is a whole new option.
I'd like to propose that we consider moving away from our traditional approach
to multilib in favor of recommending the use of a 32-bit container runtime when
needed on a 64-bit host.
## Advantages
* Simplification of build-tree creation. We wouldn't have to maintain the lists
and hacks that are required to make sure that multilib packages land in the
correct repositories.
* Less duplication of content in the mirror networks.
* It will be simpler to create module content without having to reimplement all
the multilib hacks of above. This is directly relevant to the Base Runtime
module, whose prototype is today intentionally limited to the primary
architecture (no multilib).
* Requires us to maintain and keep up-to-date the 32-bit container base images.
## Disadvantages
* If we eliminate multilib entirely, all applications that use 32-bit libs will
have to either install a 32-bit host OS or install into a container. This may be
a difficult transition for some users.
* Mitigation: develop and maintain tools to ease this transition.
* It is unlikely that any clean upgrade path would exist. (We could make it
*technically* possible, but likely not without breaking 32-bit software not
installed by RPM.
* Requires us to maintain and keep up-to-date the 32-bit container base images.
(Yes, this is both an advantage and disadvantage.)
I'll be totally frank and say this entire proposal is garbage. There
is not a reasonable way this proposal is workable. It breaks the world
because it expects that you can completely segregate applications,
which you can't. It also expects that applications can be
containerized, which there are lot of cases where you can't. And it
also completely annihilates upgrade paths and user expectations on
having things like Wine, Steam, and other common applications to work.
If we're considering rethinking multilib, I'd be more inclined to see
if we could have multi-platform libdirs like how Debian does (though
they call them "multi-arch" libdirs). This proposed approach is
essentially broken by design because it implies that applications
should be segregated. I fundamentally disagree with this, because
there are many legitimate reasons to be able to have programs that
work together that cross architectures/platforms.
Please don't do this.
--
真実はいつも一つ！/ Always, there's only one truth!
7:32 p.m.
I'm wholeheartedly against this. I also view personally containers *just*
as a thing to solve subset of real-world problems, but not a army knife
for everything. IOW, enforcing users to use containers instead of
multilib feature looks a bit hostile.
Have other distros already done this movement? I'm almost sure we
shouldn't pioneer this.
IMO: multilib && Modularization efforts && containerization efforts
shouldn't collide.
More in-line comments ...
On Thursday, January 5, 2017 11:03:50 AM CET Stephen Gallagher wrote:
## Advantages
* Simplification of build-tree creation. We wouldn't have to maintain the lists
and hacks that are required to make sure that multilib packages land in the
correct repositories.
If that's a real issue, we should avoid working on hacks, and rather
invent a new way to _declare_ some (sub)package is designed to be
multilib, I filed this:
https://pagure.io/pungi/issue/500
* Less duplication of content in the mirror networks.
That's not really duplication to me.
* It will be simpler to create module content without having to
reimplement all the multilib hacks of above. This is directly relevant
to the Base Runtime module, whose prototype is today intentionally
limited to the primary architecture (no multilib).
What's the reason to not have multilib in Base Runtime? Is that because
it is hard to experiment with multilib in copr (rhbz#1393664) or what
hacks are you referring to? The point of this remark is that there should
be a way to minimize hacks.
* Requires us to maintain and keep up-to-date the 32-bit container
base images.
This would be pros, but we should probably have 32-bit container anyways..
## Disadvantages
* If we eliminate multilib entirely, all applications that use 32-bit libs will
have to either install a 32-bit host OS or install into a container. This may be
a difficult transition for some users.
.. user apps -> this looks like absolute showstopper IMO.
Even though there are also third-party package providers like skype --
where I would personally appreciate we either forced them to move to
container or provide x86_64 packages (or if there was really sufficient
open source alternative to make them obsolete)..
But I'm afraid such third party would rather drop Fedora support, which
would be bad especially for us..
Pavel
> * Mitigation: develop and maintain tools to ease this transition.
>
> * It is unlikely that any clean upgrade path would exist. (We could make it
> *technically* possible, but likely not without breaking 32-bit software not
> installed by RPM.
>
* Requires us to maintain and keep up-to-date the 32-bit container
base images.
> (Yes, this is both an advantage and disadvantage.)
>
>
> ## Open Questions (non-exhaustive):
>
> * Can SSSD and systemd's 32-bit name-service modules work from within a
> container, talking to their host's service? Without that, 32-bit containers
> won't be able to resolve users, groups or hostnames.
>
> * Can we have 32-bit containers communicate with other local system APIs such as
> D-BUS on the host?
>
> * Do we need to care about 32-bit GUI applications on a 64-bit system? Should we
> decide that flatpak is the official answer for such cases?
>
12:02 a.m.
On Thursday, January 5, 2017, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
# Overview
For many years, Fedora has supported multilib by carrying
parallel-installable
libraries in /usr/lib[64]. This was necessary for a very long time in
order to
support 32-bit applications running on a 64-bit deployment. However, in
today's
new container world, there is a whole new option.
I'd like to propose that we consider moving away from our traditional
approach
to multilib in favor of recommending the use of a 32-bit container runtime
when
needed on a 64-bit host.
## Advantages
* Simplification of build-tree creation. We wouldn't have to maintain the
lists
and hacks that are required to make sure that multilib packages land in the
correct repositories.
* Less duplication of content in the mirror networks.
* It will be simpler to create module content without having to
reimplement all
the multilib hacks of above. This is directly relevant to the Base Runtime
module, whose prototype is today intentionally limited to the primary
architecture (no multilib).
* Requires us to maintain and keep up-to-date the 32-bit container base
images.
## Disadvantages
* If we eliminate multilib entirely, all applications that use 32-bit libs
will
have to either install a 32-bit host OS or install into a container. This
may be
a difficult transition for some users.
* Mitigation: develop and maintain tools to ease this transition.
* It is unlikely that any clean upgrade path would exist. (We could make it
*technically* possible, but likely not without breaking 32-bit software not
installed by RPM.
* Requires us to maintain and keep up-to-date the 32-bit container base
images.
(Yes, this is both an advantage and disadvantage.)
## Open Questions (non-exhaustive):
* Can SSSD and systemd's 32-bit name-service modules work from within a
container, talking to their host's service? Without that, 32-bit containers
won't be able to resolve users, groups or hostnames.
* Can we have 32-bit containers communicate with other local system APIs
such as
D-BUS on the host?
* Do we need to care about 32-bit GUI applications on a 64-bit system?
Should we
decide that flatpak is the official answer for such cases?
This proposal is more or less "let's make life a bit easier for us in
expense of our users". Your proposal shifts the hacks to the users.
There are still a lot of 32bit software out there. In stead of having it
just work you are asking users to fiddle around with hacks / jumping
through hoops.
So your proposal would cause way more harm than good.
9:09 a.m.
On Thu, 2017-01-05 at 11:03 -0500, Stephen Gallagher wrote:
# Overview
For many years, Fedora has supported multilib by carrying parallel-installable
libraries in /usr/lib[64]. This was necessary for a very long time in order to
support 32-bit applications running on a 64-bit deployment. However, in today's
new container world, there is a whole new option.
I'd like to propose that we consider moving away from our traditional approach
to multilib in favor of recommending the use of a 32-bit container runtime when
needed on a 64-bit host.
I think this is missing the developer story. I maintain a couple of
tools that currently need to handle 32-on-64-bit setups and it is a bit
of a pain. So getting rid of multilib certainly would make my life
easier. But some of those tools really do work better because they are
64-bit themselves but target 32-bit applications/libraries. It means
they can use the full 64-bit address space while reading/writing 32-bit
files/datastructures. I believe gcc and binutils/ld are in the same
category. Some applications targeting 32-bit architectures are so big
that you need 64-bit tools to just build them. Maybe this is a small
enough development story that it doesn't really matter. But it would be
good to know if developers are comfortable with a pure/native 32bit-only
development toolchain.
Thanks,
Mark
2655
days inactive
2661
days old
58 comments
32 participants
participants (32)
-
Andrew Lutomirski -
Bastien Nocera -
Ben Rosser -
Chris Adams -
Chris Murphy -
Christian Schaller -
Dan Horák -
Daniel J Walsh -
Daniel P. Berrange -
Dennis Gilmore -
drago01 -
Florian Weimer -
Japheth Cleaver -
Jonathan Wakely -
Josh Boyer -
Kevin Kofler -
M. Edward (Ed) Borasky -
Mark Wielaard -
Martin Bříza -
Matthew Miller -
Michael Cronenworth -
Neal Gompa -
Nicholas Miell -
Pavel Raiskup -
Petr Šabata -
Randy Barlow -
Richard W.M. Jones -
Stephen Gallagher -
Stephen John Smoogen -
Thorsten Leemhuis -
Tom Hughes -
Vít Ondruch