On Thu, Jan 22, 2009 at 12:17:33PM -0800, Chris Quenelle wrote: > So I hear two issues here: > > 1. /usr/compilers is a bad name because it is too generic > > Please suggest another name to give us an idea of what you're looking for. > I consider any reference to "Sun Studio" to be inappropriate because > we're not delivering all of Sun Studio, or even all of the compilers > from Sun Studio. Do you have other ideas for a good name?
If there will be just one version, and that version will be invokable through /usr/bin, then just deliver into /usr/bin /usr/lib/sunstudio (or whatever) If we want the ability to use a "links package" to control what version is available through /usr/bin, then: a) wouldn't that also be true of GCC? and b) if the version can be selected via PATH, why bother with links packages? If we drop the multiple versions (multiple versions -> /opt) and links packages (there's only one version, after all) then we don't need /usr/compilers, or /usr/foo or /usr/<whatever>. > 2. The project should anticipate delivering multiple versions > of the compilers into Nevada, and/or the project should deliver > multiple versions as part of this case. I'm happy with the "only one version in /usr, other versions in /opt" answer. I think that's a fine answer that simplifies other things. > I think there has been a lot of discussion about this already, > I really can't think of anything new to say on this topic, > but I'll give it a try. Well, I just did think of something new to add. Namely that "one version in /usr" should imply "no need for links pkgs" and "just install into /usr/bin and /usr/lib." I.e., no need for /usr/compilers.
