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