[arch-dev-public] Multilib on Archlinux x86_64
For a while now, there have been lib32-* packages in community. They sort of work for many applications, but have certain problems. This is what I don't like about them: - The naming convention (lib32-*) - The separate prefix (/opt/lib32) - The fact that the binaries are only copied from the 32 bit packages One can argue about the first two, but the third poses a real problem: Many libraries have hardcoded paths to plugin directories, like /usr/lib/gconv in glibc. If you run the glibc binary from arch32 in a 64 bit environment, glibc looks in /usr/lib/gconv for plugins, but only finds 64 bit binaries, which it can't load. Similar problems exist for many other libraries. Some can be worked around with environment variables, which is annoying, some can't. Thus, a clean solution is to rebuild all required binaries with the right paths included. I am proposing to build a new repository, let's call it [multilib] for now, which only exists on x86_64. I strictly want this to be separate from [extra], to keep our main repositories clean (however, extensions to [multilib] can still be placed in [community] IMO). GOALS: Fill in the missing pieces on x86_64: - flash - wine - possibility to install skype, teamspeak and google-earth from AUR Build all necessary libraries to install all of the above, but not more than that. APPROACH: The idea is to only install a 32 bit runtime, no complete toolchain. Packages are being built on a full 32 bit Archlinux system in the following way: The package is renamed from foo to foo-32bit (that's the naming convention I like most). All libraries are installed in /usr/lib32, only libraries are installed. It may be necessary to install exectuables, those should be put into /usr/bin in a way that they don't conflict with the normal 64 bit packages. If a library needs data files (for example in /usr/share), the package depends on the corresponding 64 bit package. makepkg must be fooled into marking the package as x86_64. This can be done by putting 'export CARCH="x86_64"' to the end of the build() function, but this is unclean (breaks with -L, possibly more). I am using a patched makepkg (not upstream yet) to introduce a 'destarch' keyword for the PKGBUILD (destarch='x86_64'). A package that can only exist in a 32 bit environment may put files into /usr/{bin,share,man,...} (but not include/), as there will never be conflicts with 64 bit packages (for example, wine will create /usr/{bin,share}/wine). Libraries must still be installed in /usr/lib32. To make all those packages work, glibc-32bit installs a symlink /lib/ld-linux.so.2 -> /usr/lib32/ld-linux.so.2. This is no problem because the 64 bit linker is called /lib/ld-linux-x86-64.so.2 (or /lib64/ld-linux-x86-64.so.2 in non-archlinux binaries). It also adds /usr/lib32 to /etc/ld.so.conf. To make ldd work, a separate ldd32 script can be installed. It would be even nicer if we could apply the following change to the ldd script in our core glibc package: < RTLDLIST="/lib/ld-linux-x86-64.so.2"
RTLDLIST="/lib/ld-linux-x86-64.so.2 /lib/ld-linux.so.2" That will make ldd work for both 32 and 64 bit binaries.
PROGRESS I have built enough packages to install flash by just running 'pacman -Sy flashplugin' (some are already out of date though). I also built libgl and intel-dri to make OpenGL work on my Intel chip, other dri modules as well as the Nvidia/Ati versions of libGL.so are on my imaginary TODO list. I didn't build enough to try wine yet, and I was going to wait with this posting until then, but I am not sure when I will get to it. So this is it, the repository (in my public_html for now): [multilib] Server = http://dev.archlinux.org/~thomas/multilib I want to hear opinions about the idea and packages. Just try it by running pacman -Sy flashplugin. I didn't upload any PKGBUILDs yet, I want to clean them up first and see if and in what way the makepkg patches are accepted upstream. I can upload some examples though. SOME RANDOM DETAILS / TWEAKS: - pango and gtk2: Both pango and gtk2 install configuration files in /etc/ that contain paths to plugins. For the 32 bit packages, I had to change the hardcoded paths in the libraries and create separate configuration files for the 32 bit plugins. I also had to install 32 bit versions of the tools that generate these configuration files. - nspluginwrapper: nspluginwrapper is split into two packages: The nspluginviewer package contains only the 32 bit binaries and is built on a 32 bit system. The nspluginwrapper package contains the 64 bit binaries and is built on a 64 bit system. In order to properly install flash, nspluginwrapper has to create a separate file that contains the location of the real plugin. I had to patch nspluginwrapper so it is possible to manually specify the directory it puts the file in (/usr/lib/mozilla/plugins by default, but I needed ${startdir}/pkg/usr/lib/mozilla/plugins). The flash package is built on 64 bit, due to the lack of the npconfig program on the 32 bit system.
You must have mixed the mailing lists! Arch64 was founded to never have support for 32bit compatibilty. So move this into the community/AUR list. I give you a strict -1 for any 32bit compat stuff in our officially supported repos as I already told you in private discussions. I've spent several weeks if not even months to make it as clean as possible. It would be a reason for me to stepdown here! -AndyRTR
Andreas Radke schrieb:
You must have mixed the mailing lists!
Actually, no.
Arch64 was founded to never have support for 32bit compatibilty. So move this into the community/AUR list.
Yeah, maybe, and I am extending it.
I give you a strict -1 for any 32bit compat stuff in our officially supported repos as I already told you in private discussions. I've spent several weeks if not even months to make it as clean as possible.
What you are saying is that by adding an extra capability (again, separate repository, nothing to pollute core or extra in any way), we destroy the clean-ness of your so clean (and yeah, it is clean) system. That's just irrational. The fact that you don't quote a single line from my posting tells me that you haven't even read any of my propositions. Why don't you give technical arguments instead of making this personal? The reason I want to maintain this on our ftp is that I want it to be easily accessible to our devs and users, as I can't maintain it alone. The reason I don't want this (at least the core of it) in community is that I want it to be separate from the rest. Besides, unless you want to maintain the packages or use them by activating the repository in pacman.conf, you won't even notice it's there.
It would be a reason for me to stepdown here!
Now you're just being childish!
Am Tue, 08 Jul 2008 20:36:42 +0200 schrieb Thomas Bächler <thomas@archlinux.org>:
The fact that you don't quote a single line from my posting tells me that you haven't even read any of my propositions. Why don't you give technical arguments instead of making this personal?
Sure this all can be done in a technically clean way not touching pure 64bit core and extra repos. It's more a question what Arch64 was founded for: to be the bleading edge leading _pure_ 64bit distro around. That's been its goal since the project has started. And I think we did a good job. You may have missed the early discussions when we made decisions that we don't want (though we have could have) multilib compatibility and bi-arch gcc. That was a strict law. It was our way to push the efforts to once get it the same level where the x86 world is. Offering 32bit compat stuff always means to make it easy for users but takes much pressure from companies and opensource developers give the x86_64 architecture the time and responsibility it is worth. You can compare it to the question to support closed source stuff or not. We made our decision long ago. So please respect it. -Andy
2008/7/8 Andreas Radke <a.radke@arcor.de>:
Offering 32bit compat stuff always means to make it easy for users but takes much pressure from companies and opensource developers give the x86_64 architecture the time and responsibility it is worth. You can compare it to the question to support closed source stuff or not. We made our decision long ago. So please respect it.
This is all very noble, but: 1) Arch Linux is not a big distribution that is going to put any pressure on companies. It doesn't make any difference that way. Hell, all the Linux distros put together can barely put any pressure on companies. 2) The core values of Arch Linux have always been based on a pragmatic approach. I'm not aware of any guideline saying Arch will deliberately exclude closed source products because they are closed source (mostly its because we can't license it). Eg: I remember when we had the JDK in the repos even though the license was, at the time, questionable. 3) Arch64 is not separate from Arch Linux, it should share these original ideals. They're two architectures under one distro, they shouldn't have different philosophies. Being noble and only supporting non-free software or non-32 bit software is for... well, Debian types. My two cents only, and I acknowledge that won't even cover the sales tax on your dollar's worth. Dusty
On Tue, Jul 8, 2008 at 3:14 PM, Dusty Phillips <buchuki@gmail.com> wrote:
3) Arch64 is not separate from Arch Linux, it should share these original ideals. They're two architectures under one distro, they shouldn't have different philosophies.
I think the issue here is that Arch64 started as a completely independently-run project, separate from "Arch-core". It was decided that x86_64 was the "wave of the future", and Arch asked the Arch64 developers to join forces - it seems as though Andreas wants the original decisions of the Arch64 team to remain honored, even though they've been "absorbed", so to speak.
Andreas Radke schrieb:
It's more a question what Arch64 was founded for: to be the bleading edge leading _pure_ 64bit distro around. That's been its goal since the project has started. And I think we did a good job.
You may have missed the early discussions when we made decisions that we don't want (though we have could have) multilib compatibility and bi-arch gcc. That was a strict law. It was our way to push the efforts to once get it the same level where the x86 world is.
I missed the discussions, maybe. But this is not a discussion we had a few years ago, this is the discussion we are having now. And just saying "A few years ago, we wanted it this way" is not a good reason.
Offering 32bit compat stuff always means to make it easy for users
No, not to make it easy, but make it possible. As I said in my reply to Daniel, I need a 64 bit OS, but I also need mixed 32/64 bit environments.
but takes much pressure from companies and opensource developers give the x86_64 architecture the time and responsibility it is worth. You can compare it to the question to support closed source stuff or not. We made our decision long ago. So please respect it.
We never denied closed source software out of principle. We always made things "just work". I want standard applications to "just work", without having to bother about which architecture I am on. Now, again, you gave me a list of ideological reasons not to do it, but where exactly is the point where this damages your "pure" system technically?
On Tue, Jul 8, 2008 at 1:36 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Andreas Radke schrieb:
I give you a strict -1 for any 32bit compat stuff in our officially supported repos as I already told you in private discussions. I've spent several weeks if not even months to make it as clean as possible.
What you are saying is that by adding an extra capability (again, separate repository, nothing to pollute core or extra in any way), we destroy the clean-ness of your so clean (and yeah, it is clean) system. That's just irrational.
The fact that you don't quote a single line from my posting tells me that you haven't even read any of my propositions. Why don't you give technical arguments instead of making this personal?
The reason I want to maintain this on our ftp is that I want it to be easily accessible to our devs and users, as I can't maintain it alone. The reason I don't want this (at least the core of it) in community is that I want it to be separate from the rest.
Besides, unless you want to maintain the packages or use them by activating the repository in pacman.conf, you won't even notice it's there.
I have to side with Thomas here on the fact that no technical arguments were brought up. That irks me just a bit - that "no because no" seems to be a valid reason. It's not. That said, I am very very neutral on this. Thomas' plan does not integrate anything at all, it just puts some 32bit libs in a parallel repo for people to use if they want to (read: users can choose). A pristine system is all well and good, but as we can all tell from the existence of the lib32- packages in community, it's not what everyone wants. What Thomas is proposing is keeping the pristine system pristine unless someone wants to install the 32bit stuff. I don't have a problem with this rationale. *But* I think it is a bit important that we look at why we're doing this - for a handful (5 or 6) closed source apps. flash, teamspeak, skype, google-earth (and wine). It seems like a lot of work for a handful of apps. That's why I'm neutral on this. I think the rationale is sound, but it sounds like a lot of forward MOTION for little forward PROGRESS.
On Tue, 8 Jul 2008 14:25:44 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On Tue, Jul 8, 2008 at 1:36 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Andreas Radke schrieb:
I give you a strict -1 for any 32bit compat stuff in our officially supported repos as I already told you in private discussions. I've spent several weeks if not even months to make it as clean as possible.
What you are saying is that by adding an extra capability (again, separate repository, nothing to pollute core or extra in any way), we destroy the clean-ness of your so clean (and yeah, it is clean) system. That's just irrational.
The fact that you don't quote a single line from my posting tells me that you haven't even read any of my propositions. Why don't you give technical arguments instead of making this personal?
The reason I want to maintain this on our ftp is that I want it to be easily accessible to our devs and users, as I can't maintain it alone. The reason I don't want this (at least the core of it) in community is that I want it to be separate from the rest.
Besides, unless you want to maintain the packages or use them by activating the repository in pacman.conf, you won't even notice it's there.
I have to side with Thomas here on the fact that no technical arguments were brought up. That irks me just a bit - that "no because no" seems to be a valid reason. It's not.
That said, I am very very neutral on this. Thomas' plan does not integrate anything at all, it just puts some 32bit libs in a parallel repo for people to use if they want to (read: users can choose). A pristine system is all well and good, but as we can all tell from the existence of the lib32- packages in community, it's not what everyone wants. What Thomas is proposing is keeping the pristine system pristine unless someone wants to install the 32bit stuff. I don't have a problem with this rationale.
*But* I think it is a bit important that we look at why we're doing this - for a handful (5 or 6) closed source apps. flash, teamspeak, skype, google-earth (and wine). It seems like a lot of work for a handful of apps. That's why I'm neutral on this. I think the rationale is sound, but it sounds like a lot of forward MOTION for little forward PROGRESS.
I really don't see the advantage to do this. Like Aaron said, there are just about 5-6 apps, which are not available on x86_64. The next thing is, why should we support it official? There are users out there which are happy with the lib32-* packages in community. The TUs are doing a great job on this. Why should we (we seen as dev) support those stuff? Why not bringing your stuff into community as a replacement for the lib32-* packages? In my opinion setting up an additional official repo just for multilib is too much work, which isn't needed (MY opinion). There is a big -1 from my side. Daniel
On Tue, Jul 8, 2008 at 3:31 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
In my opinion setting up an additional official repo just for multilib is too much work, which isn't needed (MY opinion).
Just to be clear here - I think Thomas is offering to do all the work himself, and setting up a new repo takes about 30 seconds (ssh to gerolde, run mkdir -p, exit).
On Tue, 8 Jul 2008 15:36:39 -0500 "Aaron Griffin" <aaronmgriffin@gmail.com> wrote:
On Tue, Jul 8, 2008 at 3:31 PM, Daniel Isenmann <daniel.isenmann@gmx.de> wrote:
In my opinion setting up an additional official repo just for multilib is too much work, which isn't needed (MY opinion).
Just to be clear here - I think Thomas is offering to do all the work himself, and setting up a new repo takes about 30 seconds (ssh to gerolde, run mkdir -p, exit).
Not really:
On Tue, 08 Jul 2008 20:36:42 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
The reason I want to maintain this on our ftp is that I want it to be easily accessible to our devs and users, as I can't maintain it alone. The reason I don't want this (at least the core of it) in community is that I want it to be separate from the rest.
There will be maintain effort to do and not only by Thomas, he said it in his second mail.
Daniel Isenmann schrieb:
*But* I think it is a bit important that we look at why we're doing this - for a handful (5 or 6) closed source apps. flash, teamspeak, skype, google-earth (and wine). It seems like a lot of work for a handful of apps. That's why I'm neutral on this. I think the rationale is sound, but it sounds like a lot of forward MOTION for little forward PROGRESS.
It is some work, but it is worth it. I want this because my computer is not in an ideal world where I can simply port everything to 64 bit. This is the real world, where I depend on applications I that need 32 bit environments, even worse, I depend on applications that only work in x86_64/i386 multilib environments.
I really don't see the advantage to do this. Like Aaron said, there are just about 5-6 apps, which are not available on x86_64.
See above.
The next thing is, why should we support it official?
You are all so much about terminology. The "official" part is not what this is about, but the "separate" part. I want a clean 32bit environment separate from the "normal" repositories. And if you want to call it [community-multilib] instead of multilib, fine.
There are users out there which are happy with the lib32-* packages in community. The TUs are doing a great job on this.
You haven't really read my posting. The lib32-* packages are broken by design. This is just a lot of work being done, about a good job ... that's another category.
Why should we (we seen as dev) support those stuff?
Well, because I want do, and so do others, possibly. Why should we not support it?
Why not bringing your stuff into community as a replacement for the lib32-* packages? In my opinion setting up an additional official repo just for multilib is too much work, which isn't needed (MY opinion).
1) Setting up a repository is 0 work. 2) Because it doesn't belong in community, it doesn't belong in extra or even in core. It's a different thing and it should be in its own place.
On Tue, 08 Jul 2008 23:14:04 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Daniel Isenmann schrieb:
*But* I think it is a bit important that we look at why we're doing this - for a handful (5 or 6) closed source apps. flash, teamspeak, skype, google-earth (and wine). It seems like a lot of work for a handful of apps. That's why I'm neutral on this. I think the rationale is sound, but it sounds like a lot of forward MOTION for little forward PROGRESS.
It is some work, but it is worth it. I want this because my computer is not in an ideal world where I can simply port everything to 64 bit. This is the real world, where I depend on applications I that need 32 bit environments, even worse, I depend on applications that only work in x86_64/i386 multilib environments.
I really don't see the advantage to do this. Like Aaron said, there are just about 5-6 apps, which are not available on x86_64.
See above.
The next thing is, why should we support it official?
You are all so much about terminology. The "official" part is not what this is about, but the "separate" part. I want a clean 32bit environment separate from the "normal" repositories. And if you want to call it [community-multilib] instead of multilib, fine.
There are users out there which are happy with the lib32-* packages in community. The TUs are doing a great job on this.
You haven't really read my posting. The lib32-* packages are broken by design. This is just a lot of work being done, about a good job ... that's another category.
I have read your posting!
Why should we (we seen as dev) support those stuff?
Well, because I want do, and so do others, possibly. Why should we not support it?
Is it just because you want it? Then why you are not doing it on your own as you do it already? Set up a repo somewhere and maintain it. For me it looks like, you want it and we should helping maintaining it. Ok, you have done some good work to seperate the stuff from the official repos, but then it can even exists as a private repo from you somewhere.
2) Because it doesn't belong in community, it doesn't belong in extra or even in core. It's a different thing and it should be in its own place.
See above.
Am Tue, 08 Jul 2008 23:14:04 +0200 schrieb Thomas Bächler <thomas@archlinux.org>:
2) Because it doesn't belong in community, it doesn't belong in extra or even in core. It's a different thing and it should be in its own place.
I see no reason why it can't become part of the community(TUs?) maintained repos. Or if you need it that much, why don't you setup a repo and publish it in the Arch64 wiki section. Just like Dan did it with the EEE repo. Call me Debianish but when it comes to install official support for closed crap don't count on me. -Andy
2008/7/9 Andreas Radke <a.radke@arcor.de>:
Am Tue, 08 Jul 2008 23:14:04 +0200 schrieb Thomas Bächler <thomas@archlinux.org>:
2) Because it doesn't belong in community, it doesn't belong in extra or even in core. It's a different thing and it should be in its own place.
I see no reason why it can't become part of the community(TUs?) maintained repos.
This would make community not pure x86_64 then.
Or if you need it that much, why don't you setup a repo and publish it in the Arch64 wiki section. Just like Dan did it with the EEE repo.
This is actually a valid point (and I like this way more), though see below.
Call me Debianish but when it comes to install official support for closed crap don't count on me.
I don't use wine or flash on x86_64, but there is one very good FOSS that is missing on x86_64 - VirtualBox OSE. (I'm not maintaining it in community anymore, but I think current maintainer is interested in making it available on x86_64 as well) A quote from the build instructions: On 64-bit systems you need the following packages as well: * ia32-libs (various libraries needed for compiling the 32-bit guest additions) * libc6-dev-i386 (libc6 i386 development headers) * lib32gcc1 (gcc support for i386) * gcc-multilib (gcc support for i386) * lib32stdc++6 (libstdc++ for i386) * g++-multilib (g++ support for i386) So building VirtualBox OSE is not possible with our gcc on x86_64, because it doesn't have 32-bit support (and I'm absolutely fine with this!), but with multilib repo it should be possible (requires adding gcc with 32-bit support), but then - if VirtualBox OSE will be in community then multilib repo should be either part of community or have the same status as community (you may call it community-multilib if you wish). If multilib repo will be like eee repo (e.g. "fully unofficial") then it seems x86_64 VirtualBox OSE cannot be part of community (because of dependency on unofficial repo) (and then I'm wondering about if x86_64 wine is in the same situation). -- Roman Kyrylych (Роман Кирилич)
Well, I'm not against having multilib packages about although I do think they need to be in their own repo. A wise person once said this about Arch: "It is what you make it". So if someone wants to make it multilib, then as long as I don't have to, all is good as far as I'm concerned. What I don't like is the need to build on a 32bit system. This doesn't help people who only have an x86_64 system and if you are going to install a 32bit chroot to build something then it is a bit of a waste of time... Why not provide a multilib enabled gcc et al at the same time? That would save patching makepkg to deal with the packaging. Allan
On Tue, 8 Jul 2008, Thomas Bächler wrote:
Daniel Isenmann schrieb:
*But* I think it is a bit important that we look at why we're doing this - for a handful (5 or 6) closed source apps. flash, teamspeak, skype, google-earth (and wine). It seems like a lot of work for a handful of apps. That's why I'm neutral on this. I think the rationale is sound, but it sounds like a lot of forward MOTION for little forward PROGRESS.
It is some work, but it is worth it. I want this because my computer is not in an ideal world where I can simply port everything to 64 bit. This is the real world, where I depend on applications I that need 32 bit environments, even worse, I depend on applications that only work in x86_64/i386 multilib environments.
I agree. I've been using Thomas' multilib flash for the last few days and it works fine. The open source alternatives for flash doesn't work all the time. Having a working flash on x86_64 without going through the bother of a chroot is nice.
I really don't see the advantage to do this. Like Aaron said, there are just about 5-6 apps, which are not available on x86_64.
See above.
The next thing is, why should we support it official?
You are all so much about terminology. The "official" part is not what this is about, but the "separate" part. I want a clean 32bit environment separate from the "normal" repositories. And if you want to call it [community-multilib] instead of multilib, fine.
I can't see why it would be OK to have this stuff in community but not in their own repo. As Thomas will be maintaining them in each case, the workload would be the same.
There are users out there which are happy with the lib32-* packages in community. The TUs are doing a great job on this.
You haven't really read my posting. The lib32-* packages are broken by design. This is just a lot of work being done, about a good job ... that's another category.
Why should we (we seen as dev) support those stuff?
Well, because I want do, and so do others, possibly. Why should we not support it?
I am interested in this stuff and would be willing in helping Thomas with the maintenance.
Why not bringing your stuff into community as a replacement for the lib32-* packages? In my opinion setting up an additional official repo just for multilib is too much work, which isn't needed (MY opinion).
1) Setting up a repository is 0 work. 2) Because it doesn't belong in community, it doesn't belong in extra or even in core. It's a different thing and it should be in its own place.
Having it in it's seperate repo would also unclutter the community repo. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
participants (9)
-
Aaron Griffin
-
Allan McRae
-
Andreas Radke
-
Daniel Isenmann
-
Dusty Phillips
-
Eric Belanger
-
Roman Kyrylych
-
Thomas Bächler
-
Travis Willard