From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,c06ed2b443abb1e5
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail
NNTP-Posting-Date: Mon, 02 Jan 2006 08:45:31 -0600
Date: Mon, 02 Jan 2006 09:40:20 -0500
From: Jeffrey Creem <jeff@thecreems.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: [gnuada, question] installations directory
References: <1150472.HIHOOy7jJt@linux1.krischik.com>
In-Reply-To: <1150472.HIHOOy7jJt@linux1.krischik.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <giqn83-oas.ln1@newserver.thecreems.com>
NNTP-Posting-Host: 24.147.74.171
X-Trace: 
 sv3-ezOTZv/tcnFSRKWxsr5F1EzZ8wO7CXd4kcZf95f4cKpzz+e4suILp7PFqd53idiKkSzVy1oqc5ymgnz!TCvw5Dz7qIv94B2Iw+R+KQHx173GwkZUPdnIhQskdNsDgPCP8/R/otaNuH/t+hUruXcyse9cFN7V!6LU=
X-Complaints-To: abuse@comcast.net
X-DMCA-Complaints-To: dmca@comcast.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.32
Xref: g2news1.google.com comp.lang.ada:2414
Date: 2006-01-02T09:40:20-05:00
List-Id: <comp.lang.ada>

Martin Krischik wrote:
> Hello
> 
> currently the GNU Ada projects uses /opt/gnat as installation directory.
> However it has been observed that this means on can only install one gnat
> at a time.
> 
> We could - just like GNAT/Pro on Windows - install each GNAT into a separate
> directory.
> 
> ----
> 
> Option 1 (leave as is)
> 
> /opt/gnat
> 
> 
> Option 2 (just the types):
> 
> /opt/gnat/gpl
> /opt/gnat/gcc
> 
> Disadvantage: you can still only configure one system in /etc/profile.d and 
> /etc/ld.so.conf.d.
> 
> Option 3 (inc. version);
> 
> /opt/gnat/gpl/2005
> /opt/gnat/gcc/3.4.5
> /opt/gnat/gcc/4.0.2
> 
> Disadvantage: What should "rpm --upgrade" do? Probably not what half the
> users would expect.
> 
> -----
> 
> Personally I think option 2 might be a good alternative. I am very unsure
> about option 3 as it is totally against the rpm concept and might therefore
> lead to all sorts of problems.
> 
> Martin

I think this concept is a bit like one of the other posters suggested.

In a perfect world, we would do something like

/opt/gnat/gpl
/opt/gnat/gcc

Each designed to hold the "latest" version of its flavor.

(which is sort of like option 2).

Then if the developers were really kind, we could also add something
like

/opt/gnat/locked/gcc/3.4.5
/opt/gnat/locked/gcc/4.0.2
/opt/gnat/locked/gpl/2005

(perhaps replaced locked with a better term if we can think of one).

The top leve (non-locked) would be for the mainline releases/upgrades of 
the compiler.

The ones under "locked" would only be rpm --upgradeable if we were to 
find some sort of packaging issue that required us to release a new RPM 
(e.g. a patch to something like 4.0.2 RPm to add a missing file or 
perhaps other local patches)

Of course this whole thing could get carried away in terms of the level 
of effort required for a community development.

I know for things like the sparc solaris .pkg I uploaded it takes more 
than a day to build on my old dog sparc.

The biggest problem with these multiple compiler (and other future 
component)  versions are the shared libraries. They are a real pain and 
will inevitably lead to user confusion...