[arch-general] Concurrent java environments

[w9ya at qrparci.net]

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.)