On 20/08/14 16:45, Les Mikesell wrote: > On Wed, Aug 20, 2014 at 9:02 AM, Toralf Lund <toralf.lund at pgs.com> wrote: >>>>>> I can confirm that. I have both installed. You can configure the default >>>>>> using the 'alternatives' system. >>>>> is it just me, or does anyone else think that 'alternatives' system is >>>>> completely bogus? >>>> I've always seen it as designed mostly for system services for which >>>> there are several common implementations - like the SMTP server or the >>>> printing system. Where I think it makes sense. >>> But do you really need _two_ symlinks to get a default in your PATH? >> I think the argument is that "configuration" commands shouldn't change >> bin directories. Which is right in a way, but maybe this is one of the >> cases where practicality should have been chosen over formal correctness. > What is formally correct about putting executables in some obscure > place under /var? I'm not quite sure what you mean by that. For the alternatives setup I have links on /usr/bin or whatever pointing to other links on /etc/alternatives, which in turn point to the real files - where direct links from /usr/bin would of course be simpler. Perhaps you were talking about something else, or are the locations different on CentOS 7 (I'm using version 6.) What I was referring to is that I believe it's considered as incorrect to put "dynamic" data on /usr these days. I'm not sure there is a separate specification saying so, or if it's just taken to be implied by the FHS (http://www.pathname.com/fhs/pub/fhs-2.3.html). - T > >>>> It may also be useful to be able to set up a system-wide default for >>>> user applications "with alternatives", but I suppose a user override >>>> ought to be possible in that case. >>>> >>>>> what if I have one user that wants JDK6 and another that needs JDK7 ? >>>> I guess the "preferred applications" system in the desktop is in a way >>>> meant for such cases, but this of course comes across as incomplete, too. >>>> >>> The concept used for 'software collections' is a more realistic >>> approach - but instead of hiding where things land and needing a tool >>> to set up use, why not just tell people what to add to their own PATH >>> and LD_LIBRARY path to get the version you want. That's almost >>> certainly what the developers of every package where they need to have >>> test versions does. So why treat the users like they would be too >>> dumb for that? >> That's a point. >> >> You could also easily develop "config" tools that would make that job >> easier for "dumb" users - this might be more productive than maintaining >> different solution that essentially have the same effect. > Or you could just not pretend that users are dumb for choosing your > product. And not hide the purpose, content, and functionality of PATH > and LD_LIBRARY_PATH, things that every developer who needs to have a > 'stable, trusted' version of an application along with today's build > is going to understand and utilize. So it's probably not those > developers that came up with the weird alternatives scheme - or at > least decided to use it for applications that really need concurrent > alternatives, not a site-wide default. > This e-mail, including any attachments and response string, may contain proprietary information which is confidential and may be legally privileged. It is for the intended recipient only. If you are not the intended recipient or transmission error has misdirected this e-mail, please notify the author by return e-mail and delete this message and any attachment immediately. If you are not the intended recipient you must not use, disclose, distribute, forward, copy, print or rely on this e-mail in any way except as permitted by the author.