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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,a19f7b11143e52d2 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.68.MISMATCH!feeder.news-service.com!feed.xsnews.nl!border-1.ams.xsnews.nl!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: One united Ada policy for all Linux distributions? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <8b775424-6d49-4fc1-8f9d-f1837d75371e@e21g2000vbl.googlegroups.com> <15rwx3bkqj8p9$.18lm12fadj9m7$.dlg@40tude.net> <5txqlpw1cur0$.11swneejphjyt.dlg@40tude.net> <1b6eaaf6-5f27-446d-8bfc-3327823b1085@o15g2000vbb.googlegroups.com> Date: Tue, 18 May 2010 16:00:03 +0200 Message-ID: <18bgyygvhvbcj$.2m8ra7tyeeq0$.dlg@40tude.net> NNTP-Posting-Date: 18 May 2010 16:00:03 CEST NNTP-Posting-Host: 27eb9501.newsspool1.arcor-online.net X-Trace: DXC=821F On Tue, 18 May 2010 06:09:25 -0700 (PDT), Ludovic Brenta wrote: > Dmitry A. Kazakov wrote on comp.lang.ada: >> On Tue, 18 May 2010 03:19:36 -0700 (PDT), Ludovic Brenta wrote: >>> Dmitry A. Kazakov wrote on comp.lang.ada: >>>> If we wanted to introduce versioning (coexistence in Debian policy terms?), >>>> we could hang version suffixes on the gpr's directory, rather than on gpr >>>> files. The suffix will follow GNAT releases. >> >>> That would be too restrictive; it would not allow you to have e.g. two >>> versions of a library with the same compiler. >> >> Why? Each GNAT (gnatmake, gprbuild) would search its project directory >> first. It should be no different from the way the standard library ads >> files are handled - transparently to the user. > > In both Debian and GNAT GPL Edition, you can actually choose between > two versions of the standard library: zero-cost and setjump/longjump. > But that aside, the standard library is tightly coupled to the > compiler, so it makes sense to install it in a compiler-dependent > location. On the contrary, third-party libraries are *not* tightly > coupled to the compiler, have different release cycles, and should > therefore *not* be in a compiler-dependent location. It is a bad idea > to artificially tie some version of a third-party library with some > version of the compiler. Theoretically tue, but in practice *-dev packages depend on the compiler package anyway. At least ALIs must be recompiled, otherwise GNAT will complain. So I don't see it as an additional restriction. >>> This is no better than >>> the GNAT GPL distribution as you noted. �So the versioning would have >>> to use the aliversion in the names of the .gpr files, possibly with a >>> versionless symlink to the default versioned project file, e.g.: >> >>> /usr/share/ada/adainclude/gtkada2.14.2.gpr >>> /usr/share/ada/adainclude/gtkada2.18.gpr >>> /usr/share/ada/adainclude/gtkada.gpr -> gtkada2.14.2.gpr >> >> That would mean version-dependent gpr files. This is what we have now. BTW, >> it probably won't work, because the project name is checked against the >> file name. >> >> The idea is that the name of a gpr file never changes, so you do not need >> to modify your gpr file each time a new gtkada version comes. You don't >> need to modify it for another Linux. > > Ah but sometimes a new version of a library breaks source > compatibility with existing programs. Suppose that Debian and Fedora > both provide /usr/share/ada/adainclude/x.gpr; this file comes from the > package libx1-dev in Debian and from libx2-devel in Fedora. Suppose > that X version 1 and X version 2 are incompatible at the source level. > Your user program that compiles cleanly on Debian will not compile on > Fedora and vice versa. How would you propose to address this in a > "unified" policy? Isn't it to be resolved at the package level? If my package requires the package x version 1 (but not x version 2), I should state this in "Requires." > How do you propose to address this in your user- > written program? When a new version of x comes, I must test against it and make a new release for it, if necessary. 100% upward compatibility does not exist. as we all know. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de