Re: One united Ada policy for all Linux distributions?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

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