The latest Wine RPMs are compiled without BiDi support
the Red Hat rpms may be, but I can assure you that your help to get bidi into the mdk rpms wasn't invane.
Ivan Leo Murray-Smith wrote:
The latest Wine RPMs are compiled without BiDi support
the Red Hat rpms may be, but I can assure you that your help to get bidi into the mdk rpms wasn't invane.
Greedy ol' me, trying to get them all :-)
Shachar
Le mar 09/09/2003 à 10:14, Shachar Shemesh a écrit :
Ivan Leo Murray-Smith wrote:
The latest Wine RPMs are compiled without BiDi support
the Red Hat rpms may be, but I can assure you that your help to get bidi into the mdk rpms wasn't invane.
Greedy ol' me, trying to get them all :-)
I am the RH package manager for Wine. My RPMS are indeed without BiDi support for now, as I was aiming for them to be rebuildable on any fully-updated (and nothing more) RH box. Of course, I can install the required libraries and build them with BiDi support if you push me to it :)
Vincent
On 9 Sep 2003, Vincent Béron wrote:
I am the RH package manager for Wine. My RPMS are indeed without BiDi support for now, as I was aiming for them to be rebuildable on any fully-updated (and nothing more) RH box.
Shouldn't the configure script take care of that?
Vincent Béron wrote:
Le mar 09/09/2003 à 10:14, Shachar Shemesh a écrit :
Ivan Leo Murray-Smith wrote:
The latest Wine RPMs are compiled without BiDi support
the Red Hat rpms may be, but I can assure you that your help to get bidi into the mdk rpms wasn't invane.
Greedy ol' me, trying to get them all :-)
I am the RH package manager for Wine. My RPMS are indeed without BiDi support for now, as I was aiming for them to be rebuildable on any fully-updated (and nothing more) RH box. Of course, I can install the required libraries and build them with BiDi support if you push me to it :)
Vincent
As all you have to do is have a local copy of the ICU library in order to get BiDi support in (and configure will autodetect it), I don't think having your RPMs compiled with BiDi support will hurt in any way. Your SRPMS will still be compilable on any platform (except, of course, that the compiled version will not have BiDi support. That, however, is up to each individual person).
I (as well as many of the Israeli and Arab community) would much appretiate if you could do the extra effort, as well as hear feedback.
Shachar
On Tue, 09 Sep 2003 19:09:04 +0300 Shachar Shemesh wine-devel@shemesh.biz wrote:
I am the RH package manager for Wine. My RPMS are indeed without BiDi support for now, as I was aiming for them to be rebuildable on any fully-updated (and nothing more) RH box. Of course, I can install the required libraries and build them with BiDi support if you push me to it :)
Vincent
As all you have to do is have a local copy of the ICU library in order
to get BiDi support in (and configure will autodetect it), I don't think having your RPMs compiled with BiDi support will hurt in any way. Your SRPMS will still be compilable on any platform (except, of course, that the compiled version will not have BiDi support. That, however, is up to each individual person).
I think you should be considering multiple, alternative packages. Yes, I know it is more work, but even the current packages have dependencies on things that some people consider un-necessary and avoidable.
Far too many packagers seem to want to add everything including the kitchen sink in, the end result is packages that are a right royal PITA if you are trying to install on a small system.
Keith Matthews wrote:
On Tue, 09 Sep 2003 19:09:04 +0300 Shachar Shemesh wine-devel@shemesh.biz wrote:
I am the RH package manager for Wine. My RPMS are indeed without BiDi support for now, as I was aiming for them to be rebuildable on any fully-updated (and nothing more) RH box. Of course, I can install the required libraries and build them with BiDi support if you push me to it :)
Vincent
As all you have to do is have a local copy of the ICU library in order
to get BiDi support in (and configure will autodetect it), I don't think having your RPMs compiled with BiDi support will hurt in any way. Your SRPMS will still be compilable on any platform (except, of course, that the compiled version will not have BiDi support. That, however, is up to each individual person).
I think you should be considering multiple, alternative packages. Yes, I know it is more work, but even the current packages have dependencies on things that some people consider un-necessary and avoidable.
Far too many packagers seem to want to add everything including the kitchen sink in, the end result is packages that are a right royal PITA if you are trying to install on a small system.
That is precisely the reason BiDi requires no hard dependancies. If ICU is available during compilation, it will be available on the end system without any further packages required (statically linked into Wine). You will also find that most other packages are soft dependancies. I.e. - they are not required in order to make Wine work. If they are there, they will be used. If you don't want them, don't install them, and you still get Wine.
Shachar
Le mar 09/09/2003 à 12:50, Keith Matthews a écrit :
On Tue, 09 Sep 2003 19:09:04 +0300 Shachar Shemesh wine-devel@shemesh.biz wrote:
I am the RH package manager for Wine. My RPMS are indeed without BiDi support for now, as I was aiming for them to be rebuildable on any fully-updated (and nothing more) RH box. Of course, I can install the required libraries and build them with BiDi support if you push me to it :)
Vincent
As all you have to do is have a local copy of the ICU library in order
to get BiDi support in (and configure will autodetect it), I don't think having your RPMs compiled with BiDi support will hurt in any way. Your SRPMS will still be compilable on any platform (except, of course, that the compiled version will not have BiDi support. That, however, is up to each individual person).
I think you should be considering multiple, alternative packages. Yes, I know it is more work, but even the current packages have dependencies on things that some people consider un-necessary and avoidable.
Far too many packagers seem to want to add everything including the kitchen sink in, the end result is packages that are a right royal PITA if you are trying to install on a small system.
The opposite (as Debian does it) is a slew of small packages for the whole Wine functionality. So if you don't install wine-print, you can't load winspool.drv, and some apps (even some from which you don't use the print facility) won't load. It's a semi-common problem on IRC.
The best way is, as Alexandre tries to go, run-time detection. Yes the executables are bigger (more functionality), but there's not more installation-time dependancies and it can use some more libs as they are installed.
Vincent
On September 9, 2003 10:18 am, Vincent Béron wrote:
Le mar 09/09/2003 à 12:50, Keith Matthews a écrit :
On Tue, 09 Sep 2003 19:09:04 +0300
snip
I think you should be considering multiple, alternative packages. Yes, I know it is more work, but even the current packages have dependencies on things that some people consider un-necessary and avoidable.
Far too many packagers seem to want to add everything including the kitchen sink in, the end result is packages that are a right royal PITA if you are trying to install on a small system.
The opposite (as Debian does it) is a slew of small packages for the whole Wine functionality. So if you don't install wine-print, you can't load winspool.drv, and some apps (even some from which you don't use the print facility) won't load. It's a semi-common problem on IRC.
The best way is, as Alexandre tries to go, run-time detection. Yes the executables are bigger (more functionality), but there's not more installation-time dependancies and it can use some more libs as they are installed.
Vincent
, except that rpm insists on the appropriate packages being installed before it will even install the wine. Personally my environment is for business computing. I only have a sound card because it is on the board; I don't have speakers. So I have no need for sound, scanner support, camera support and all the other things that a lot of people do want. Therefore I find it extremely frustrating when I have to install packages purely to satisfy an rpm requirement.
, except that rpm insists on the appropriate packages being installed before it will even install the wine. Personally my environment is for business computing. I only have a sound card because it is on the board; I don't have speakers. So I have no need for sound, scanner support, camera support and all the other things that a lot of people do want. Therefore I find it extremely frustrating when I have to install packages purely to satisfy an rpm requirement.
The method used will not require a rpm dependency, the libraries are optional.
Ciao, Marcus
Bill Medland wrote:
On September 9, 2003 10:18 am, Vincent Béron wrote:
The best way is, as Alexandre tries to go, run-time detection. Yes the executables are bigger (more functionality), but there's not more installation-time dependancies and it can use some more libs as they are installed.
Vincent
, except that rpm insists on the appropriate packages being installed before it will even install the wine. Personally my environment is for business computing. I only have a sound card because it is on the board; I don't have speakers. So I have no need for sound, scanner support, camera support and all the other things that a lot of people do want. Therefore I find it extremely frustrating when I have to install packages purely to satisfy an rpm requirement.
Then talk to your RPM packager and have him remove those packages from the "depends" for the RPM. As Wine can handle pretty fine without them, there is no reason to list them under "depends". With Debian, you can list those packages under "recommends" or "suggests". RPM has no such facilities, unfortunetly.
Shachar
Le mar 09/09/2003 à 13:47, Bill Medland a écrit :
, except that rpm insists on the appropriate packages being installed before it will even install the wine. Personally my environment is for business computing. I only have a sound card because it is on the board; I don't have speakers. So I have no need for sound, scanner support, camera support and all the other things that a lot of people do want. Therefore I find it extremely frustrating when I have to install packages purely to satisfy an rpm requirement.
Here's the list of dependencies for a freshly built Wine package on RH9: shadow-utils /bin/sh /bin/sh /bin/sh /bin/sh rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 /bin/sh
The devel package adds a couple perl modules to this.
As you can see, there's no dependency anymore on arts, sane, etc. as they're detected at run-time. This package has been built on a full install of RH9 (minus kernel-source for disk space shortness).
Vincent
Le mar 09/09/2003 à 12:09, Shachar Shemesh a écrit :
As all you have to do is have a local copy of the ICU library in order to get BiDi support in (and configure will autodetect it), I don't think having your RPMs compiled with BiDi support will hurt in any way. Your SRPMS will still be compilable on any platform (except, of course, that the compiled version will not have BiDi support. That, however, is up to each individual person).
Will do (if Alexandre doesn't release the next version today) :)
I (as well as many of the Israeli and Arab community) would much appretiate if you could do the extra effort, as well as hear feedback.
Do you personnally use either RH8 or 9? Or is there a way for me (without knowing how to read those two languages) to know if it works?
Vincent
Vincent Béron wrote:
Le mar 09/09/2003 à 12:09, Shachar Shemesh a écrit :
I (as well as many of the Israeli and Arab community) would much appretiate if you could do the extra effort, as well as hear feedback.
Do you personnally use either RH8 or 9? Or is there a way for me (without knowing how to read those two languages) to know if it works?
Yes. I posted the source for a small program that tests this. It's available at http://www.winehq.org/hypermail/wine-devel/2003/08/0175.html.
Vincent
There is one gotcha that still needs to be looked into. It appears that even when ICU is statically linked, some versions look for files on the HD. The ICU support forum said this should not happen with 2.6. What this means, however, is that it may well be that you will build the package on your machine (where ICU is installed), and then test it and see it working. Other people, however, will not get BiDi unless they install ICU as well (despite it being statically linked). I have sent the Israeli community to have a look at existing packages, to see whether this has happened so far. I'll be most glad to help anyone who enoucnters this problem to solve it. In the mean while, it is important to test, at least once, your package on a computer other than the one that was used to generate it.
Shachar
Le mar 09/09/2003 à 13:33, Shachar Shemesh a écrit :
Yes. I posted the source for a small program that tests this. It's available at http://www.winehq.org/hypermail/wine-devel/2003/08/0175.html.
Thanks.
There is one gotcha that still needs to be looked into. It appears that even when ICU is statically linked, some versions look for files on the HD. The ICU support forum said this should not happen with 2.6. What this means, however, is that it may well be that you will build the package on your machine (where ICU is installed), and then test it and see it working. Other people, however, will not get BiDi unless they install ICU as well (despite it being statically linked). I have sent the Israeli community to have a look at existing packages, to see whether this has happened so far. I'll be most glad to help anyone who enoucnters this problem to solve it. In the mean while, it is important to test, at least once, your package on a computer other than the one that was used to generate it.
That's exactly what I have as symptom. I installed ICU 2.6 as RPMs (from the IBM site), then compiled Wine and verified that your program succeded (it did), then removed the ICU RPMs and retried your program, and it failed. After just reinstalling the ICU RPMs, it worked again.
So there's a problem with the static linking. Probably it's not enough (I think there are some data files which are needed also).
Vincent
-
Bill Medland -
Dimitrie O. Paun -
Ivan Leo Murray-Smith -
Keith Matthews -
Marcus Meissner -
Shachar Shemesh -
Vincent Béron