Hello,
I was wondering - why jre/jdk packages conflict with java-gcj-compat? Unless I missed something there are no file conflicts (since jre and jdk are in /opt) and I think the rest (switching between the environments when necessary) could be done be (re)setting of environment variables (such as $PATH and $JAVA_HOME). Or am I overlooking something?
Being a java developer (at least from time to time) I am in need of Sun implementation (actually even of version 6), on the other hand on x86_64 the webplugin from gcc-gcj in combination with java-gcj-compat is the only way to run some applets (e. g. those that need security certificates; for other applets only gcc-gcj might be enough).
Ondřej
On Sun, 2008-02-24 at 04:21 +0100, Ondřej Kučera wrote:
Hello,
I was wondering - why jre/jdk packages conflict with java-gcj-compat? Unless I missed something there are no file conflicts (since jre and jdk are in /opt) and I think the rest (switching between the environments when necessary) could be done be (re)setting of environment variables (such as $PATH and $JAVA_HOME). Or am I overlooking something?
Being a java developer (at least from time to time) I am in need of Sun implementation (actually even of version 6), on the other hand on x86_64 the webplugin from gcc-gcj in combination with java-gcj-compat is the only way to run some applets (e. g. those that need security certificates; for other applets only gcc-gcj might be enough).
Ondřej
You could install gcc-gcj and symlink the web plugin in the right directory without installing java-gcj-compat. The reason why we have it conflicting is because we want to have only one complete java solution installed on a system.
Hi,
You could install gcc-gcj and symlink the web plugin in the right directory without installing java-gcj-compat.
Yes. But sadly, as I was saying, that won't work for applets using certificates because they would be looking for files like /usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/security/cacerts and those (actually I'm not sure if this is the only such a file or if there are more) are a part of java-gcj-compat. So because of this one may really need java-gcj-compat.
The reason why we have it conflicting is because we want to have only one complete java solution installed on a system.
OK and the reason for this is which? :-) Shouldn't this be up to the user? Does it have some real drawbacks to have more than one java installed? I on the other hand can imagine that someone is developing java applications and wants to test it against gcj, Sun's java, IBM's java and perhaps even some others - why should it be a problem unless there are some technical difficulties in setting up the environments?
Ondřej
Comments and a solution offered below:
Hi,
You could install gcc-gcj and symlink the web plugin in the right directory without installing java-gcj-compat.
Yes. But sadly, as I was saying, that won't work for applets using certificates because they would be looking for files like /usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre/lib/security/cacerts and those (actually I'm not sure if this is the only such a file or if there are more) are a part of java-gcj-compat. So because of this one may really need java-gcj-compat.
The reason why we have it conflicting is because we want to have only one complete java solution installed on a system.
OK and the reason for this is which? :-) Shouldn't this be up to the user? Does it have some real drawbacks to have more than one java installed? I on the other hand can imagine that someone is developing java applications and wants to test it against gcj, Sun's java, IBM's java and perhaps even some others - why should it be a problem unless there are some technical difficulties in setting up the environments?
I see a HUGE headache is asking the user to deal with "changing paths" just so a few users can have two java implementations installed. Or even worse asking some sort of software to 'automagically' switch such declarations. there is nothing but grief in going that route with little to gain except for those highly specific usages of a untypical and quite unusual user such as yourself.
i.e. There is nothing whatsoever K.I.S.S. in what you are asking for. And ArchLinux is *very* SPECIFICALLY a K.I.S.S. style distribution.
however all is not lost for you since there *IS* both abs AND a way to track specialized PKGBUILDs on specific and particular machines. A user such as yourself CAN (!) choose to do the things YOU desire without asking Arch to accommodate what you ask for. i.e. You can do this for yourself quite easily using the Arch-way once you determine EXACTLY how to accomplish your configuration. I would suggest you read up on customizing PKGBUILDs so you can facilitate YOUR specific needs.
Very best regards;
Bob Finch
Ondøej
-- Cheers, Ondøej Kuèera
Hi,
I see a HUGE headache is asking the user to deal with "changing paths" just so a few users can have two java implementations installed. Or even worse asking some sort of software to 'automagically' switch such declarations. there is nothing but grief in going that route with little to gain except for those highly specific usages of a untypical and quite unusual user such as yourself.
i.e. There is nothing whatsoever K.I.S.S. in what you are asking for. And ArchLinux is *very* SPECIFICALLY a K.I.S.S. style distribution.
however all is not lost for you since there *IS* both abs AND a way to track specialized PKGBUILDs on specific and particular machines. A user such as yourself CAN (!) choose to do the things YOU desire without asking Arch to accommodate what you ask for. i.e. You can do this for yourself quite easily using the Arch-way once you determine EXACTLY how to accomplish your configuration. I would suggest you read up on customizing PKGBUILDs so you can facilitate YOUR specific needs.
I think you misunderstood my intentions. I certainly don't want users to deal with changing paths if that was what it took. But I don't think this is necessary. The way I see it is this: now users can have one and only one java implementation. They can choose whether it is based on GNU's gcj+classpath or Sun's jre/jdk. Either way as long is the java application is "sane" and doesn't need Java 6 features (which are afaik not included in gcj), it will run OK.
If Arch provided a way to have both environments installed, nothing needs to be changed for normal users. They would choose one of the environments and everything would run as smoothly as it does now, that's the beauty of it and I don't see where it contradicts KISS.
Only some users who want to have more choice would install both environments. There would have to be one default, frankly I don't care which but probably it would be easier if it was the GNU's because it is in /usr/bin. If such an advanced user needed to run some application under Sun's java, they would probably only need to write a simple script which would put /opt/java/bin at the start of $PATH and perhaps set $JAVA_HOME. But this wouldn't have to be done by all users like you were saying, I would never suggest something like that.
So actually I disagree, I think what I'm asking still complies to KISS. I mean one of the points of using Linux is to have a choice - you can choose your distribution, you can choose your favorite video player, you can choose your favorite PDF reader and you can choose to install three or five of them so that you can switch if you have a video file that your favorite player is unable to play or a PDF file that your favorite PDF reader has trouble printing. One of the reasons I chose ArchLinux was because it has so many packages available and most of them I can have installed at the same time. That's why I'm surprised that such a decision was taken not because there was some technical difficulty but because somebody felt that (almost) no one needs more than one java.
Yes you're right, there is ABS and I can just rebuild my own jre/jdk packages. The only problem is - one of the other reasons why I chose ArchLinux was that the major "everyday" packages are prepared and I don't have to compile them myself. And it feels rather strange (and actually this I find a little contradictory to KISS) having to rebuild both packages with the only change to the PKGBUILDs in the way that I would change their "conflicts" line (perhaps I could actually use the binary packages and tell pacman to ignore dependencies).
In conclusion, I don't want to fight or argue or be offensive in any way. If I'm missing something important that would make life of other users more complicated, please tell me. But so far I don't see what it is in my request (actually it started as more of a question really) that would complicate things for users that want to have only one java installed (which would be probably the most of them).
Ondřej
There should be nothing philosophically against having multiple javae installed, if allowing concurrent installations just needs a change in paths (and updating the conflicts arrays).
You could compare the situation to the many lisp implementations that can be installed concurrently without problems; maybe we should make all editors conflict, as that would keep everything simple :)
Comments inserted, where it seems prudent, below:
Hi,
Hey there !!;
I see a HUGE headache is asking the user to deal with "changing paths" just so a few users can have two java implementations installed. Or even worse asking some sort of software to 'automagically' switch such declarations. there is nothing but grief in going that route with little to gain except for those highly specific usages of a untypical and quite unusual user such as yourself.
i.e. There is nothing whatsoever K.I.S.S. in what you are asking for. And ArchLinux is *very* SPECIFICALLY a K.I.S.S. style distribution.
however all is not lost for you since there *IS* both abs AND a way to track specialized PKGBUILDs on specific and particular machines. A user such as yourself CAN (!) choose to do the things YOU desire without asking Arch to accommodate what you ask for. i.e. You can do this for yourself quite easily using the Arch-way once you determine EXACTLY how to accomplish your configuration. I would suggest you read up on customizing PKGBUILDs so you can facilitate YOUR specific needs.
I think you misunderstood my intentions. I certainly don't want users to deal with changing paths if that was what it took. But I don't think this is necessary. The way I see it is this: now users can have one and only one java implementation. They can choose whether it is based on GNU's gcj+classpath or Sun's jre/jdk. Either way as long is the java application is "sane" and doesn't need Java 6 features (which are afaik not included in gcj), it will run OK.
I dunno anything about your intentions, and they are not particularly relevant to discussing what you want either as far as I can tell.
O.K.. on your saying no path declarations. I am glad we can agree on that.
If Arch provided a way to have both environments installed, nothing needs to be changed for normal users. They would choose one of the environments and everything would run as smoothly as it does now, that's the beauty of it and I don't see where it contradicts KISS.
Nor do I if NOTHING installing these two programs creates NO need to change anything related to messing with system environmental settings. SO....I guess I didn't understand you earlier about the $PATH stuff being required so as not to break things.
Only some users who want to have more choice would install both environments. There would have to be one default, frankly I don't care which but probably it would be easier if it was the GNU's because it is in /usr/bin. If such an advanced user needed to run some application under Sun's java, they would probably only need to write a simple script which would put /opt/java/bin at the start of $PATH and perhaps set $JAVA_HOME. But this wouldn't have to be done by all users like you were saying, I would never suggest something like that.
OOPPSSS !!
Looks like you REALLY DID mean for $PATH to be changing !! If not I am clearly confused.
And even that confusion would not be so bad, BUT what you SEEM to be proposing does NOT appear be clear as to when, and to what, and why any specific setting would be better or more useful in any particular machine. <- Until those things are clearly defined, (which you do not seem to have clearly presented herein btw,) I would suggest that any changes are not desired at this time.
Or put as succinctly as I can muster; I just do NOT understand what it is you want because the details seem to be missing, and your meaning is not clear, to me, without more details.
So actually I disagree, I think what I'm asking still complies to KISS. I mean one of the points of using Linux is to have a choice - you can choose your distribution, you can choose your favorite video player, you can choose your favorite PDF reader and you can choose to install three or five of them so that you can switch if you have a video file that your favorite player is unable to play or a PDF file that your favorite PDF reader has trouble printing. One of the reasons I chose ArchLinux was because it has so many packages available and most of them I can have installed at the same time. That's why I'm surprised that such a decision was taken not because there was some technical difficulty but because somebody felt that (almost) no one needs more than one java.
IF you have create odd issues with $PATH due to which of two different programs are installed that ostensibly do the same thing, well then that is no longer K.I.S.S. IMHO.
EXACTLY to the point:
But there really is a solution. *Script* up what you want things to work like and submit that to the developers.
If the $PATH stuff, removal of any Conflict field in the various PKGBUILDs, and whatnot -> all result in things NOT getting broken in the process; Well I rather think you will have not only gotten what you ask for, but will have given all of us a solution you can be proud of.
And I will have learned something new in the process, and will be grateful for the lesson.
Yes you're right, there is ABS and I can just rebuild my own jre/jdk packages. The only problem is - one of the other reasons why I chose ArchLinux was that the major "everyday" packages are prepared and I don't have to compile them myself. And it feels rather strange (and actually this I find a little contradictory to KISS) having to rebuild both packages with the only change to the PKGBUILDs in the way that I would change their "conflicts" line (perhaps I could actually use the binary packages and tell pacman to ignore dependencies).
Cool, that was the more important point of my earlier message to you. If things are not the way you want them with Arch, the package management instead of being adverse to changes from the normative setup, actually encourages and easily allows for YOUR special needs.
i.e. You need NOT go to developers to solve the conundrum you are asking for.
In conclusion, I don't want to fight or argue or be offensive in any way. If I'm missing something important that would make life of other users more complicated, please tell me. But so far I don't see what it is in my request (actually it started as more of a question really) that would complicate things for users that want to have only one java installed (which would be probably the most of them).
And I am very glad you got the necessary point about ANYONE being able to use the Arch supplied tools to craft a solution to the issue you wanted to discuss.
Very best regards;
Bob Finch
Ondøej
-- Regards, Ondøej Kuèera
Hello,
all right, I'll try an example, hopefully that will help, perhaps I'm not choosing the best words to express myself (English isn't my native language, that's probably obvious).
Say we have to java applications, application A which can be run only under GNU's java (and not Sun's) and application B which can be run only under Sun's (and not GNU's).
As of now, the (hypothetical) user is in one of these two situations.
(1) They have java-gcj-compat installed. So, tu run A, they have to use the following command: run-A.sh To run B, however, they have to use the following commands: pacman -R java-gcj-compat pacman -S jre run-B.sh Also note that they cannot run A and B at the same time. (And now that I think of it they would also need to ensure that /etc/profile.d/jre.sh was run before run-B.sh...)
(2) They have jre installed. Similarly, it is easy to run B: run-B.sh but rather difficult tu run A: pacman -R jre pacman -S java-gcj-compat run-A.sh
Now imagine that it would indeed be possible to have java-gcj-compat and jre installed at the same time. Then:
(3) To run A: run-A.sh To run B: PATH=/opt/java/bin:$PATH run-B.sh
Now tell me - of these three situations - which seems the simplest (the most KISS) to you? I mean yes - if the only measure of simplicity for you is whether or not you have to manually reset $PATH for one command, than (3) is more complicated but, my opinion is that (1) and (2) are much worse for the user.
I dunno anything about your intentions, and they are not particularly relevant to discussing what you want either as far as I can tell.
I think they are. Are they now clearer?
O.K.. on your saying no path declarations. I am glad we can agree on that.
Yes, globally, i. e. I don't want any serious messing with for example /etc/profile if that would be what it takes. Changing one environment variable ad hoc to run one program is imho something that more or less everybody does on a daily basis.
Looks like you REALLY DID mean for $PATH to be changing !! If not I am clearly confused.
Yes, but only in the way specified above.
And even that confusion would not be so bad, BUT what you SEEM to be proposing does NOT appear be clear as to when, and to what, and why any specific setting would be better or more useful in any particular machine. <- Until those things are clearly defined, (which you do not seem to have clearly presented herein btw,) I would suggest that any changes are not desired at this time.
Or put as succinctly as I can muster; I just do NOT understand what it is you want because the details seem to be missing, and your meaning is not clear, to me, without more details.
Does the example above help?
IF you have create odd issues with $PATH due to which of two different programs are installed that ostensibly do the same thing, well then that is no longer K.I.S.S. IMHO.
My opinion is that the issues with $PATH that we are talking about are not very odd. And again as I said earlier - each Linux distribution has tons of programs that do the same thing, serve the same purpose - why should suddenly java be an exception?
EXACTLY to the point:
But there really is a solution. *Script* up what you want things to work like and submit that to the developers.
If the $PATH stuff, removal of any Conflict field in the various PKGBUILDs, and whatnot -> all result in things NOT getting broken in the process; Well I rather think you will have not only gotten what you ask for, but will have given all of us a solution you can be proud of.
And I will have learned something new in the process, and will be grateful for the lesson.
Cool, that was the more important point of my earlier message to you. If things are not the way you want them with Arch, the package management instead of being adverse to changes from the normative setup, actually encourages and easily allows for YOUR special needs.
i.e. You need NOT go to developers to solve the conundrum you are asking for.
Please, return once more to my original post. I was merely asking "why" and saying "I think it could be done some way". What I expected was one of these answers: (1) An interesting idea. We never thought about it but it sounds promising, we'll look into it. (2) An interesting idea but not interesting enough (or not with much priority), we don't have time to explore it. If you want, try to make it work yourself and if you succeed, let us know. (3) Can't be done. We tried it and the problem was that <insert_a_reason>... (4) A dumb idea, you're an idiot. Clearly anyone can see that it simply cannot be done because <insert_a_reason>.
What I got instead was not that it can't be done, but that it won't be done, and not actually one solid argument pointing to where there really are some serious difficulties.
So no, I didn't do more research than that I spent some time thinking about whether it might or might not work, I never said I did. I asked because I thought someone might have done that in the past (which would mean that I would be just repeating something that was bound to be doomed) or that someone sees further than I do and can immediately see why it would never work. I don't have the step-by-step solution you're talking about. If I did, this whole conversation would be pointless. But you make it seem as if even asking about whether something was already tried (or seems possible at all) is wrong unless I spend hours or days finding my own solution.
And I am very glad you got the necessary point about ANYONE being able to use the Arch supplied tools to craft a solution to the issue you wanted to discuss.
Yes and also anyone is able to use their favorite editor and gcc to make their own operating system. Yet not many people do so because the time they would spend learning how to do it would be enormous. For the same reason not everyone can be an ArchLinux developer, not everyone has the knowledge and though many people would be capable of acquiring this knowledge, most of them don't have the time. So yes, I could spend the hours recompiling both java environments from the source and juggling with PKGBUILDs and maybe I even will but the point is that I wanted to find out if perhaps someone already tried that or saw a solution that would take minutes instead of hours (or hours instead of days). I really don't see what was so horribly wrong with my question.
Ondřej
Comments inserted below;
Hello,
all right, I'll try an example, hopefully that will help, perhaps I'm not choosing the best words to express myself (English isn't my native language, that's probably obvious).
Say we have to java applications, application A which can be run only under GNU's java (and not Sun's) and application B which can be run only under Sun's (and not GNU's).
As of now, the (hypothetical) user is in one of these two situations.
(1) They have java-gcj-compat installed. So, tu run A, they have to use the following command: run-A.sh To run B, however, they have to use the following commands: pacman -R java-gcj-compat pacman -S jre run-B.sh Also note that they cannot run A and B at the same time. (And now that I think of it they would also need to ensure that /etc/profile.d/jre.sh was run before run-B.sh...)
(2) They have jre installed. Similarly, it is easy to run B: run-B.sh but rather difficult tu run A: pacman -R jre pacman -S java-gcj-compat run-A.sh
Now imagine that it would indeed be possible to have java-gcj-compat and jre installed at the same time. Then:
(3) To run A: run-A.sh To run B: PATH=/opt/java/bin:$PATH run-B.sh
Now tell me - of these three situations - which seems the simplest (the most KISS) to you? I mean yes - if the only measure of simplicity for you is whether or not you have to manually reset $PATH for one command, than (3) is more complicated but, my opinion is that (1) and (2) are much worse for the user.
I dunno anything about your intentions, and they are not particularly relevant to discussing what you want either as far as I can tell.
I think they are. Are they now clearer?
O.K.. on your saying no path declarations. I am glad we can agree on that.
Yes, globally, i. e. I don't want any serious messing with for example /etc/profile if that would be what it takes. Changing one environment variable ad hoc to run one program is imho something that more or less everybody does on a daily basis.
Looks like you REALLY DID mean for $PATH to be changing !! If not I am clearly confused.
Yes, but only in the way specified above.
And even that confusion would not be so bad, BUT what you SEEM to be proposing does NOT appear be clear as to when, and to what, and why any specific setting would be better or more useful in any particular machine. <- Until those things are clearly defined, (which you do not seem to have clearly presented herein btw,) I would suggest that any changes are not desired at this time.
Or put as succinctly as I can muster; I just do NOT understand what it is you want because the details seem to be missing, and your meaning is not clear, to me, without more details.
Does the example above help?
IF you have create odd issues with $PATH due to which of two different programs are installed that ostensibly do the same thing, well then that is no longer K.I.S.S. IMHO.
My opinion is that the issues with $PATH that we are talking about are not very odd. And again as I said earlier - each Linux distribution has tons of programs that do the same thing, serve the same purpose - why should suddenly java be an exception?
EXACTLY to the point:
But there really is a solution. *Script* up what you want things to work like and submit that to the developers.
If the $PATH stuff, removal of any Conflict field in the various PKGBUILDs, and whatnot -> all result in things NOT getting broken in the process; Well I rather think you will have not only gotten what you ask for, but will have given all of us a solution you can be proud of.
And I will have learned something new in the process, and will be grateful for the lesson.
Cool, that was the more important point of my earlier message to you. If things are not the way you want them with Arch, the package management instead of being adverse to changes from the normative setup, actually encourages and easily allows for YOUR special needs.
i.e. You need NOT go to developers to solve the conundrum you are asking for.
Please, return once more to my original post. I was merely asking "why" and saying "I think it could be done some way". What I expected was one of these answers: (1) An interesting idea. We never thought about it but it sounds promising, we'll look into it. (2) An interesting idea but not interesting enough (or not with much priority), we don't have time to explore it. If you want, try to make it work yourself and if you succeed, let us know.
While I cannot speak IN ANY WAY for the developers, the above option is probably close to where things should be.
AND>... YES, now you can finish this better example you presented above with proper scripts to restore any changes to $PATH as needed, as well as what the run<whatever>.sh scripts consist of, and any restorations they might entail, and so forth. Then:
Because of the AUR, *you* can present alternative PKGBUILDs there for appraisal and use. You DO have this alternative AND further, you are no required to talk to or even solicit the devs. I thought you got this last part from what you said in an earlier message. But apparently you want to argue about why you expect the devs. to respond to you affirmatively. <- The point *IS* that you and they need never communicate and this in no way prevents you from submitting YOUR solution into the AUR. Just be sure to name it somehow *different* form any other package(s) and use the appropriate fields in the PKGBUILD to prevent pacman from trying to install your particular java(s) and the devs.'s version fothe same packages.
Very best regards;
Bob Finch
(3) Can't be done. We tried it and the problem was that <insert_a_reason>... (4) A dumb idea, you're an idiot. Clearly anyone can see that it simply cannot be done because <insert_a_reason>.
What I got instead was not that it can't be done, but that it won't be done, and not actually one solid argument pointing to where there really are some serious difficulties.
So no, I didn't do more research than that I spent some time thinking about whether it might or might not work, I never said I did. I asked because I thought someone might have done that in the past (which would mean that I would be just repeating something that was bound to be doomed) or that someone sees further than I do and can immediately see why it would never work. I don't have the step-by-step solution you're talking about. If I did, this whole conversation would be pointless. But you make it seem as if even asking about whether something was already tried (or seems possible at all) is wrong unless I spend hours or days finding my own solution.
And I am very glad you got the necessary point about ANYONE being able to use the Arch supplied tools to craft a solution to the issue you wanted to discuss.
Yes and also anyone is able to use their favorite editor and gcc to make their own operating system. Yet not many people do so because the time they would spend learning how to do it would be enormous. For the same reason not everyone can be an ArchLinux developer, not everyone has the knowledge and though many people would be capable of acquiring this knowledge, most of them don't have the time. So yes, I could spend the hours recompiling both java environments from the source and juggling with PKGBUILDs and maybe I even will but the point is that I wanted to find out if perhaps someone already tried that or saw a solution that would take minutes instead of hours (or hours instead of days). I really don't see what was so horribly wrong with my question.
Ondøej
-- Regards, Ondøej Kuèera
Liviu Librescu - În veci pomenirea lui. (May his memory be eternal.)
If you want to change paths and/or other environment variables, maybe /etc/profile.d is the place to put a declaration; everything in /opt needs it.
If you wanted to disable it being sourced almost permanently, you could just have it chmod 644 instead of 755
While regular users can call those scripts from their own .bash_profile etc.
* On Sunday, February 24 2008, Ondřej Kučera wrote:
Hello,
I was wondering - why jre/jdk packages conflict with java-gcj-compat? Unless I missed something there are no file conflicts (since jre and jdk are in /opt) and I think the rest (switching between the environments when necessary) could be done be (re)setting of environment variables (such as $PATH and $JAVA_HOME). Or am I overlooking something?
Being a java developer (at least from time to time) I am in need of Sun implementation (actually even of version 6), on the other hand on x86_64 the webplugin from gcc-gcj in combination with java-gcj-compat is the only way to run some applets (e. g. those that need security certificates; for other applets only gcc-gcj might be enough).
Ondřej
-- Cheers, Ondřej Kučera
arch-general@lists.archlinux.org