Re: [gnuada, question] installations directory

[Martin Krischik <krischik@users.sourceforge.net>]

Jeffrey Creem wrote:

> 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.

That is my thinking as well. While option 2 could be done with a "one off" 
of 1 hour attended and about 24 hours unattended option 3 would lead to a
constant extra effort.

> 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...

That is another point. While at work we do use option 3 for vms and Linux we
(not me - someone else ;-) ) get paid for the effort of creating and
maintaining all the versions - but for comunity package I am not sure if it
is worth the effort.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com