[arch-general] Concurrent java environments

[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


-- 
Regards,
Ondřej Kučera