So, multiarch is going along well in Debian/Ubuntu, and by next distro release Wine should be building as a proper multiarch package. Previous hacks like ia32-libs will be dead for good.
A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon.
From what I understand, this change is originating in Debian (and thus
propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained.
This means for bi-arch Wine, we will need to either: - Make Wine support building in pure 64-bit mode and then calling the 32-bit subsystem from a separate binary - Make a very persuasive case that Wine isn't the only package that needs to have multiple architectures at build time
Hopefully I'm overestimating the amount of work involved, as this sort of architecture modularity might be a "nice to have" in Wine anyway.
If none of this is doable by next release, we'll just have a 32-bit only Wine, which isn't really any worse than the situation now.
-Scott Ritchie
Scott Ritchie wrote:
So, multiarch is going along well in Debian/Ubuntu, and by next distro release Wine should be building as a proper multiarch package. Previous hacks like ia32-libs will be dead for good.
A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon.
From what I understand, this change is originating in Debian (and thus propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained.
This means for bi-arch Wine, we will need to either:
- Make Wine support building in pure 64-bit mode and then calling the
32-bit subsystem from a separate binary
- Make a very persuasive case that Wine isn't the only package that
needs to have multiple architectures at build time
Hopefully I'm overestimating the amount of work involved, as this sort of architecture modularity might be a "nice to have" in Wine anyway.
If none of this is doable by next release, we'll just have a 32-bit only Wine, which isn't really any worse than the situation now.
http://wiki.winehq.org/Wine64ForPackagers
bye michael
On Thu, May 19, 2011 at 11:58:47AM -0700, Scott Ritchie wrote:
So, multiarch is going along well in Debian/Ubuntu, and by next distro release Wine should be building as a proper multiarch package. Previous hacks like ia32-libs will be dead for good.
A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon.
From what I understand, this change is originating in Debian (and thus propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained.
This means for bi-arch Wine, we will need to either:
- Make Wine support building in pure 64-bit mode and then calling the
32-bit subsystem from a separate binary
- Make a very persuasive case that Wine isn't the only package that
needs to have multiple architectures at build time
Hopefully I'm overestimating the amount of work involved, as this sort of architecture modularity might be a "nice to have" in Wine anyway.
If none of this is doable by next release, we'll just have a 32-bit only Wine, which isn't really any worse than the situation now.
It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one.
You just need to take care you can install both.
For openSUSE I create the binary packages:
wine-32bit (i586 build) /usr/lib/libwine* /usr/lib/wine/* /usr/bin/wine /usr/bin/wine-preloader
wine (both a i586 and x86_64 package) both requires the wine-32bit package Contain all other files not in wine-32bit.
for 64bit also the runtime things /usr/lib64/libwine* /usr/lib64/wine/* /usr/bin/wine64 /usr/bin/wine64-preloader
So basically depending on which architecture it is installed on, you get wine and wine-32bit on the final system ... Just on 64bit the wine package is 64bit.
There is no need for 32bit and 64bit cross usage during build.
Ciao, Marcus
On 5/19/11 1:51 PM, Marcus Meissner wrote:
It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one.
Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'.
James McKenzie
On 5/19/11 1:51 PM, Marcus Meissner wrote:
It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one.
Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'.
James McKenzie
On Sat, May 21, 2011 at 05:57:40PM -0700, James McKenzie wrote:
On 5/19/11 1:51 PM, Marcus Meissner wrote:
It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one.
Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'.
Not sure what you mean.
If you install 64 bit wine + 32bit stuff I listed, you will have a 64+32 bit capable wine setup.
Ciao, Marcus
On 5/21/11 11:51 PM, Marcus Meissner wrote:
On Sat, May 21, 2011 at 05:57:40PM -0700, James McKenzie wrote:
On 5/19/11 1:51 PM, Marcus Meissner wrote:
It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one.
Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'.
Not sure what you mean.
If you install 64 bit wine + 32bit stuff I listed, you will have a 64+32 bit capable wine setup.
That was the answer I was looking for. Thank you, Marcus. The ability is already there. So, if I install 64 bit wine on a 64 bit machine it should work something like what Windows does now, one directory (wineprefix) for 64 bitness and one directory (wineprefix) for 32 bitness.
James McKenzie
On Sun, May 22, 2011 at 06:26:45AM -0700, James McKenzie wrote:
On 5/21/11 11:51 PM, Marcus Meissner wrote:
On Sat, May 21, 2011 at 05:57:40PM -0700, James McKenzie wrote:
On 5/19/11 1:51 PM, Marcus Meissner wrote:
It is trivial. You basically build wine twice, once in the 32bit environment and once inthe 64bit one.
Maybe Wine can look into some sort of merge process to build both and at runtime select one or the other? I don't know if this is possible, I'm just 'throwing the idea out there'.
Not sure what you mean.
If you install 64 bit wine + 32bit stuff I listed, you will have a 64+32 bit capable wine setup.
That was the answer I was looking for. Thank you, Marcus. The ability is already there. So, if I install 64 bit wine on a 64 bit machine it should work something like what Windows does now, one directory (wineprefix) for 64 bitness and one directory (wineprefix) for 32 bitness.
wineprefix for the installed .exe and .dlls? as in ~/.wine/ ?
A 64bit install and/or a 32bit install will use just 1 wineprefix (~/.wine)
If the setup is done by the 64bit binary, it will be set up in away that both 64 and 32bit windows binaries will work.
But 64bit and 32bit ~/.wine are not seperate.
Ciao, Marcus
Den 19. mai 2011 20:58, skrev Scott Ritchie:
A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon.
Well, I don't see the problem. I've been more concerned that there's not yet any clean way to get the 64-bit package to depend on the 32-bit package, but for the build itself, it's quite trivial. (At least it was a year ago or so, and I can't imagine it has gotten worse since then.)
From what I understand, this change is originating in Debian (and thus propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained.
No. Very, very, far from it.
The multiarch specs are created and maintained by a Ubuntu (and Debian) developer, and the motivations are purely user-oriented - making it possible, easy, and reliable for the user to do things that's currently difficult, fragile, and error-prone. But for package maintainers, life will certainly be no easier.
Multiarch has no management implications whatsoever for the build daemons. All official Debian architectures are perfectly self-contained as they are. (Some of them currently contain cross-compiled pieces of other architectures, which would go away, but that does not concern the build daemons or the infrastructure.)
On 05/21/2011 08:20 AM, Ove Kåven wrote:
Den 19. mai 2011 20:58, skrev Scott Ritchie:
A side effect of this change, however, is the current build daemons ONLY have packages for one architecture. This means that, at build time, you won't be able to pull in the 32-bit packages on a 64-bit build daemon.
Well, I don't see the problem. I've been more concerned that there's not yet any clean way to get the 64-bit package to depend on the 32-bit package, but for the build itself, it's quite trivial. (At least it was a year ago or so, and I can't imagine it has gotten worse since then.)
Well now we can just Depends: wine:i386 or similar, I think.
From what I understand, this change is originating in Debian (and thus propagating to Ubuntu). I believe the motivations are mostly ease of management of the build daemons -- only by doing this, for instance, can an entire architecture be properly isolated and self-contained.
No. Very, very, far from it.
The multiarch specs are created and maintained by a Ubuntu (and Debian) developer, and the motivations are purely user-oriented - making it possible, easy, and reliable for the user to do things that's currently difficult, fragile, and error-prone. But for package maintainers, life will certainly be no easier.
I don't mean the multiarch change, I mean the "build daemons will not allow have foreign multiarch build dependencies" change, which I guess isn't a change so much as it is a property of the new system.
You're quite right that multiarch proper is for users; it's something I've been demanding for a while now.
Multiarch has no management implications whatsoever for the build daemons. All official Debian architectures are perfectly self-contained as they are. (Some of them currently contain cross-compiled pieces of other architectures, which would go away, but that does not concern the build daemons or the infrastructure.)
Multiarch with foreign architecture build support would eliminate the self-containment, wouldn't it?
Den 21. mai 2011 19:38, skrev Scott Ritchie:
Well now we can just Depends: wine:i386 or similar, I think.
Last time I asked, they said the first multiarch implementation will not support that. The implementation cost of that would be very high (among other things, it might violate the current architecture self-containment), and the number of packages needing it is too small.
I don't mean the multiarch change, I mean the "build daemons will not allow have foreign multiarch build dependencies" change, which I guess isn't a change so much as it is a property of the new system.
Well that's not any different from how it works now. There wouldn't be any management implications of that.
Multiarch has no management implications whatsoever for the build daemons. All official Debian architectures are perfectly self-contained as they are. (Some of them currently contain cross-compiled pieces of other architectures, which would go away, but that does not concern the build daemons or the infrastructure.)
Multiarch with foreign architecture build support would eliminate the self-containment, wouldn't it?
As far as the infrastructure is concerned, it is the runtime dependencies that are important.
Until now, nothing in Debian had foreign architecture support, apart from Arch:all packages (which don't really count), which is why we now have the abomination that is ia32-libs. For the first version of multiarch, the buildds and dak are not going to change - only the package managers (and package build tools) would need to be aware of multiarch. Maybe foreign architecture support for the archive tools are added later, maybe not. Either way, infrastructure maintenance is not going to get easier.
On 05/22/2011 03:53 AM, Ove Kåven wrote:
Den 21. mai 2011 19:38, skrev Scott Ritchie:
Well now we can just Depends: wine:i386 or similar, I think.
Last time I asked, they said the first multiarch implementation will not support that. The implementation cost of that would be very high (among other things, it might violate the current architecture self-containment), and the number of packages needing it is too small.
Looking at the spec, it seems like Depends: wine:i386 isn't allowed, however we can create a unique package name that only exists on i386 (eg wine32), declare it Multiarch: foreign, and then have wine depend on wine32.
Den 22. mai 2011 21:48, skrev Scott Ritchie:
On 05/22/2011 03:53 AM, Ove Kåven wrote:
Den 21. mai 2011 19:38, skrev Scott Ritchie:
Well now we can just Depends: wine:i386 or similar, I think.
Last time I asked, they said the first multiarch implementation will not support that. The implementation cost of that would be very high (among other things, it might violate the current architecture self-containment), and the number of packages needing it is too small.
Looking at the spec, it seems like Depends: wine:i386 isn't allowed, however we can create a unique package name that only exists on i386 (eg wine32), declare it Multiarch: foreign, and then have wine depend on wine32.
Yes, that was what I was thinking of doing if I had to. But it's really not very clean...
-
James McKenzie -
Marcus Meissner -
Michael Stefaniuc -
Ove Kåven -
Scott Ritchie