[arch-dev-public] At last, clean multilib support
Jan Steffens and me spent the this weekend putting together a multilib toolchain and a clean lib32-glibc package. I wanted to do this for at least two years, and we finally managed to do it on FrOSCon now. This is the plan of attack on this: * Maintain the PKGBUILDs in svn-community/${pkgname}/trunk/ * Create a separate repo 'multilib', (svn-community/${pkgname}/repos/multilib-x86_64) * Remove ALL multilib packages from community. Do NOT mix pure 64 bit with multilib. All multilib must go into the new multilib repository. * Rebuild all multilib packages with the multilib compiler to solve the numerous problems encountered by the hackish "copy our 32 bit packages into another path" approach. * Find TUs and Devs willing to work on multilib (please add your name to https://wiki.archlinux.org/index.php/Multilib_Project) Any comments are welcome. We will upload the multilib packages and PKGBUILDs into a small test repository in a minute for review.
Am 22.08.2010 10:39, schrieb Thomas Bächler:
Jan Steffens and me spent the this weekend putting together a multilib toolchain and a clean lib32-glibc package. I wanted to do this for at least two years, and we finally managed to do it on FrOSCon now. This is the plan of attack on this:
* Maintain the PKGBUILDs in svn-community/${pkgname}/trunk/ * Create a separate repo 'multilib', (svn-community/${pkgname}/repos/multilib-x86_64) * Remove ALL multilib packages from community. Do NOT mix pure 64 bit with multilib. All multilib must go into the new multilib repository. * Rebuild all multilib packages with the multilib compiler to solve the numerous problems encountered by the hackish "copy our 32 bit packages into another path" approach. * Find TUs and Devs willing to work on multilib (please add your name to https://wiki.archlinux.org/index.php/Multilib_Project)
Any comments are welcome. We will upload the multilib packages and PKGBUILDs into a small test repository in a minute for review.
A temporary repository is up: http://pkgbuild.com/~heftig/multilib/
We had several discussions about lib32 and multilib support in the past. It has been always our agreement to keep Arch x86_64 plain pure 64bit. Just KISS. Any additional 32bit support should stay in the community area. Nothing has changed here. So please take care about the word "official" in this forum thread: https://bbs.archlinux.org/viewtopic.php?id=102973 or wherever it will come up. -Andy
Am 23.08.2010 12:00, schrieb Andreas Radke:
We had several discussions about lib32 and multilib support in the past. It has been always our agreement to keep Arch x86_64 plain pure 64bit. Just KISS.
It has been YOUR agreement.
Any additional 32bit support should stay in the community area. Nothing has changed here.
We are doing more than that. We are separating 32bit support from community, too. I want to make it a strict rule that no multilib package can ever enter community again. Or core. Or extra. (Btw, that rule would imply that grub is being removed from core-x86_64). To repeat what I said several times: multilib support MUST be in its own repository, the core/extra/community Arch Linux MUST stay pure 64.
So please take care about the word "official" in this forum thread: https://bbs.archlinux.org/viewtopic.php?id=102973 or wherever it will come up.
It is official in a sense that it is maintained by Arch developers and TUs.
On Mon, Aug 23, 2010 at 12:35 PM, Thomas Bächler
Am 23.08.2010 12:00, schrieb Andreas Radke:
We had several discussions about lib32 and multilib support in the past. It has been always our agreement to keep Arch x86_64 plain pure 64bit. Just KISS.
It has been YOUR agreement.
Any additional 32bit support should stay in the community area. Nothing has changed here.
We are doing more than that. We are separating 32bit support from community, too. I want to make it a strict rule that no multilib package can ever enter community again. Or core. Or extra. (Btw, that rule would imply that grub is being removed from core-x86_64).
when did we have the discussion to move to grub2 as standard? But well, I agree with Andreas, we should at least have a discussion before we change something as drastic as this, this is the first time I hear about providing official support for it and it to be already official?
To repeat what I said several times: multilib support MUST be in its own repository, the core/extra/community Arch Linux MUST stay pure 64.
so people are forced to go multilib on i686 due to grub? I mean, it must be enabled by default how else can people install it? What is the solution you propose here?
So please take care about the word "official" in this forum thread: https://bbs.archlinux.org/viewtopic.php?id=102973 or wherever it will come up.
It is official in a sense that it is maintained by Arch developers and TUs.
Ronald
Am 23.08.2010 12:43, schrieb Ronald van Haren:
Any additional 32bit support should stay in the community area. Nothing has changed here.
We are doing more than that. We are separating 32bit support from community, too. I want to make it a strict rule that no multilib package can ever enter community again. Or core. Or extra. (Btw, that rule would imply that grub is being removed from core-x86_64).
when did we have the discussion to move to grub2 as standard?
I was just messing with Andy. The fact is that grub-legacy is a 32 bit package.
But well, I agree with Andreas, we should at least have a discussion before we change something as drastic as this, this is the first time I hear about providing official support for it and it to be already official?
We do not change anything. We are just adding a new repository and we are removing tons of broken packages from community.
To repeat what I said several times: multilib support MUST be in its own repository, the core/extra/community Arch Linux MUST stay pure 64.
so people are forced to go multilib on i686 due to grub? I mean, it must be enabled by default how else can people install it? What is the solution you propose here?
As I said, I am not planning to do anything about grub, I was just pointing the flaw in Andy's argument.
On 23 August 2010 18:43, Ronald van Haren
But well, I agree with Andreas, we should at least have a discussion before we change something as drastic as this, this is the first time I hear about providing official support for it and it to be already official?
I was a little surprised at this myself, because I have had to tell others in the past about the strict rule against multilib. It used to be that there was no support at all. Then it slowly gained traction in community (hence support from TUs). So I asked Thomas on IRC what this was all about, and he made me see the obvious. Separating all this business into one lone repository removes all the mess from community. If I understood this right, this will then be a separate project, contributed to and supported by any interested Developer or TU. So in essence, it is as "official" as community, but no more and no less. -- GPG/PGP ID: B42DDCAD
On 2010/8/23 Thomas Bächler
We are doing more than that. We are separating 32bit support from community, too. I want to make it a strict rule that no multilib package can ever enter community again. Or core. Or extra. (Btw, that rule would imply that grub is being removed from core-x86_64).
To repeat what I said several times: multilib support MUST be in its own repository, the core/extra/community Arch Linux MUST stay pure 64.
What kind of packages are expected to be found in a multilib repository? Should we keep with core/extra packages, leaving 32-bit versions of community packages to AUR ? In more down-to-earth terms: are we going to have glibc/gtk2/firefox/flashplugin in the same place ?
On Mon, 2010-08-23 at 12:54 +0200, Rémy Oudompheng wrote:
What kind of packages are expected to be found in a multilib repository? Should we keep with core/extra packages, leaving 32-bit versions of community packages to AUR ? In more down-to-earth terms: are we going to have glibc/gtk2/firefox/flashplugin in the same place ?
Firefox probably not, but a 32bit flashplugin and its dependencies are one of the candidates. Another thing that comes to mind is Wine, as there's no native 64bit port of that available. At this moment community is crowded with broken 32bit crap which is just i686 packages copied to a different location (in /opt... ew), where hardcoded configuration files still point to the old i686 locations. An example of this is gtk2 trying to load 64bit plugins all the time.
On 2010/8/23, Jan de Groot
On Mon, 2010-08-23 at 12:54 +0200, Rémy Oudompheng wrote:
What kind of packages are expected to be found in a multilib repository? Should we keep with core/extra packages, leaving 32-bit versions of community packages to AUR ? In more down-to-earth terms: are we going to have glibc/gtk2/firefox/flashplugin in the same place ?
Firefox probably not, but a 32bit flashplugin and its dependencies are one of the candidates. Another thing that comes to mind is Wine, as there's no native 64bit port of that available.
At this moment community is crowded with broken 32bit crap which is just i686 packages copied to a different location (in /opt... ew), where hardcoded configuration files still point to the old i686 locations. An example of this is gtk2 trying to load 64bit plugins all the time.
Did I miss something or the 32 bit flashplugin can only be used in a 32-bit browser ? Wouldn't it be unconvenient to have the plugin in the repo without some widely used browser ? As for Wine, do I understand correctly if I say that there is (newly introduced) 64-bit support in Wine but it would only work with native 64-bit Windows binaries, and since most Windows programs are still compiled as 32-bit, bin32-wine is usually needed ? -- Rémy
On Mon, 2010-08-23 at 13:16 +0200, Rémy Oudompheng wrote:
Did I miss something or the 32 bit flashplugin can only be used in a 32-bit browser ? Wouldn't it be unconvenient to have the plugin in the repo without some widely used browser ?
As for Wine, do I understand correctly if I say that there is (newly introduced) 64-bit support in Wine but it would only work with native 64-bit Windows binaries, and since most Windows programs are still compiled as 32-bit, bin32-wine is usually needed ?
That's why there will be nspluginwrapper. That is a 64bit browser plugin that can load 32bit plugins. It was the common way of using flash in a 64bit browser before Adobe released a 64bit flash plugin. As for wine, I have no idea about what it supports with what architecture, but AFAIK there's still no working x86_64 version that runs win32 applications.
Am 23.08.2010 12:54, schrieb Rémy Oudompheng:
What kind of packages are expected to be found in a multilib repository? Should we keep with core/extra packages, leaving 32-bit versions of community packages to AUR ? In more down-to-earth terms: are we going to have glibc/gtk2/firefox/flashplugin in the same place ?
Right now, I am looking at five potential milestones: - wine (we are already working on that, see the progress in the wiki) - nspluginwrapper/flashplugin - virtualbox_ose (needs a real multilib compiler to build on x86_64) - skype (needs qt, which is huge, so maybe this will take a while) - SDL and friends, to support binary-only 32 bit games I do not see the need for any more packages than that, and my hope is that the number will reduce over time, not increase.
On Mon, 23 Aug 2010 12:00:14 +0200, Andreas Radke
We had several discussions about lib32 and multilib support in the past. It has been always our agreement to keep Arch x86_64 plain pure 64bit. Just KISS.
Any additional 32bit support should stay in the community area. Nothing has changed here.
Having this multilib repository actually ensures that our main repos will stay pure x86_64. ATM we have lib32 packages and even a cross-compiler in [community]. Those will be moved to a dedicated repository to keep things separated. Not having a multilib compiler etc. in our main repos is still sane and KISS.
So please take care about the word "official" in this forum thread: https://bbs.archlinux.org/viewtopic.php?id=102973 or wherever it will come up.
This thread has no meaning; neither has the word "official" for a community driven project like Arch. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 22.08.2010 10:39, schrieb Thomas Bächler:
Jan Steffens and me spent the this weekend putting together a multilib toolchain and a clean lib32-glibc package. I wanted to do this for at least two years, and we finally managed to do it on FrOSCon now. This is the plan of attack on this:
* Maintain the PKGBUILDs in svn-community/${pkgname}/trunk/ * Create a separate repo 'multilib', (svn-community/${pkgname}/repos/multilib-x86_64) * Remove ALL multilib packages from community. Do NOT mix pure 64 bit with multilib. All multilib must go into the new multilib repository. * Rebuild all multilib packages with the multilib compiler to solve the numerous problems encountered by the hackish "copy our 32 bit packages into another path" approach. * Find TUs and Devs willing to work on multilib (please add your name to https://wiki.archlinux.org/index.php/Multilib_Project)
Any comments are welcome. We will upload the multilib packages and PKGBUILDs into a small test repository in a minute for review.
Mailing list is up, the discussion will continue there. http://mailman.archlinux.org/mailman/listinfo/arch-multilib
participants (7)
-
Andreas Radke
-
Jan de Groot
-
Pierre Schmitz
-
Ray Rashif
-
Ronald van Haren
-
Rémy Oudompheng
-
Thomas Bächler