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!news1.google.com!proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!uninett.no!news.net.uni-c.dk!dotsrc.org!news.dotsrc.org!not-for-mail Message-ID: <5571873.juvkK3OH3u@linux1.krischik.com> From: Martin Krischik Subject: Re: [gnuada, question] installations directory Newsgroups: comp.lang.ada Date: Mon, 02 Jan 2006 17:46:01 +0100 References: <1150472.HIHOOy7jJt@linux1.krischik.com> User-Agent: KNode/0.10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Organization: SunSITE.dk - Supporting Open source NNTP-Posting-Host: 84.74.134.212 X-Trace: news.sunsite.dk DXC=oV2eCdfEclgMMDg2]64EMfYSB=nbEKnkklY5`=Xnj1SoS5daR30PdPeV:_8RJBabHmg9KO4?]BWOkin]iS88C7ijGNG]N2LL_Yg X-Complaints-To: staff@sunsite.dk Xref: g2news1.google.com comp.lang.ada:2417 Date: 2006-01-02T17:46:01+01:00 List-Id: 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