One united Ada policy for all Linux distributions?

One united Ada policy for all Linux distributions?

[Ludovic Brenta]

Dmitry A. Kazakov wrote on comp.lang.ada:
> is it possible to have one united Ada policy for all Linux distributions?
>
> Linux Ada community is small, all people are known. Can't we use this as an
> advantage here?

I would love to see that happen but unfortunately the Ada
*distribution maintainer* community is even smaller than the Linux Ada
community. The current state, as I see it:

* several people on the GNU Ada project[1] work on SuSE, Mac OS X and
a couple others. Unfortunately their work is not part of the official
distributions they target, i.e. they are "outsiders".
* one person would like to emulate the Debian policy for Ada on
FreeBSD[2].
* one person would like to emulate the Debian policy for Ada on
AuroraUX[3].
* one person works on Gentoo. No recent news on comp.lang.ada however.
* one person works on Fedora and has made two packages.
* four maintainers plus a couple of occasional contributors are active
on Debian; there is a snowball effect as these maintainers pool
resources and build on the existing, solid foundation.
* several users such as yourself have recently switched to Debian
because of the better support for Ada. This adds to the snowball
effect as these users can contribute useful bug reports and
suggestions, as you just did.

[1] http://gnuada.sourceforge.net/
[2] http://lists.freebsd.org/pipermail/freebsd-ports/2009-November/057661.html
[3] http://forums.auroraux.org/viewtopic.php?f=12&t=24

--
Ludovic Brenta.

Re: One united Ada policy for all Linux distributions?

[Ludovic Brenta]

Further musings on this hypothetical "unified" policy:

- The policy would have to mandate package names so they are the same
across distributions.

- The policy would have to mandate a minimal set of packages that must
be provided in all distributions.

- For this, the policy for package names might conflict with
distribution-wide policies about package names.  For example, in
Debian, detached debugging symbols must be in packages with names
ending with -dbg while Fedora uses -debuginfo instead.  Also the
Fedora -debuginfo packages must contain the sources while the Debian -
dbg packages may not.

- The package names must change when the ALI files change (the Debian
Policy for Ada explains why in detail; this is not specific to Debian
but is a consequence of the Ada language definition, so must apply to
all distributions).

- The release cycles are different for all distributions.  Therefore,
at any point in time, each distribution would provide a different
collection of the compiler and of all libraries, using different
package names.  This may or may not have an impact on user programs
and compilation commands.

- Therefore, a grand unified, cross-distribution policy for Ada is
theoretically impossible; only a minimalistic policy would be
possible.

- The closest thing we have currently is GNAT GPL Edition: it is cross-
platform and minimalistic (compiler, IDE, some tools and a small
selection of libraries in source-only form).

--
Ludovic Brenta.

Re: One united Ada policy for all Linux distributions?

[Dmitry A. Kazakov]

On Tue, 18 May 2010 02:32:40 -0700 (PDT), Ludovic Brenta wrote:

> Further musings on this hypothetical "unified" policy:
> 
> - The policy would have to mandate package names so they are the same
> across distributions.

Yes

> - The policy would have to mandate a minimal set of packages that must
> be provided in all distributions.

Yes
 
> - For this, the policy for package names might conflict with
> distribution-wide policies about package names.  For example, in
> Debian, detached debugging symbols must be in packages with names
> ending with -dbg while Fedora uses -debuginfo instead.  Also the
> Fedora -debuginfo packages must contain the sources while the Debian -
> dbg packages may not.

Naming of the derived packages is IMO of minor importance. It is OK to have
gtkada-dev and gtkada-devel, so long "gtkada" is same.

> - The package names must change when the ALI files change (the Debian
> Policy for Ada explains why in detail; this is not specific to Debian
> but is a consequence of the Ada language definition, so must apply to
> all distributions).

Do you mean version suffix?

> - The release cycles are different for all distributions.  Therefore,
> at any point in time, each distribution would provide a different
> collection of the compiler and of all libraries, using different
> package names.  This may or may not have an impact on user programs
> and compilation commands.

Yes, when using plain gnatmake with -I, -L stuff. (Who cares?)

No, when project files used. The project file names must be invariant. E.g.
gtkada.gpr. Ideally gpr files should be installed where GPS, gprbuild,
gnatmake could look after them. GNAT GPL's GPS does it in
<GNAT-root>/lib/gnat. I think the policy should mandate a directory under
/usr/lib or /usr/include for all gpr files rather than project-dependent
directories.

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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: One united Ada policy for all Linux distributions?

[Ludovic Brenta]

Dmitry A. Kazakov wrote on comp.lang.ada:
> On Tue, 18 May 2010 02:32:40 -0700 (PDT), Ludovic Brenta wrote:
>> - The package names must change when the ALI files change (the Debian
>> Policy for Ada explains why in detail; this is not specific to Debian
>> but is a consequence of the Ada language definition, so must apply to
>> all distributions).
>
> Do you mean version suffix?

I mean the "aliversion" which must be somewhere in the package name,
e.g. in libgtkada2.14.2-dev the aliversion is 2.14.2.  It does not
have to be a suffix; it only has to be present.

>> - The release cycles are different for all distributions.  Therefore,
>> at any point in time, each distribution would provide a different
>> collection of the compiler and of all libraries, using different
>> package names.  This may or may not have an impact on user programs
>> and compilation commands.
>
> Yes, when using plain gnatmake with -I, -L stuff. (Who cares?)
>
> No, when project files used. The project file names must be invariant. E.g.
> gtkada.gpr. Ideally gpr files should be installed where GPS, gprbuild,
> gnatmake could look after them. GNAT GPL's GPS does it in
> <GNAT-root>/lib/gnat. I think the policy should mandate a directory under
> /usr/lib or /usr/include for all gpr files rather than project-dependent
> directories.

Debian uses the proposed "standard": /usr/share/ada/adainclude and
patches libgnatprj.so to look there for project files.  libgnatprj.so
is shared between all GNAT tools and GPS and, in the future, gprbuild.
(in the mean time, gprbuild is patched too).

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

--
Ludovic Brenta.

Re: One united Ada policy for all Linux distributions?

[Dmitry A. Kazakov]

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.

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: One united Ada policy for all Linux distributions?

[Ludovic Brenta]

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.

>> 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? How do you propose to address this in your user-
written program?

--
Ludovic Brenta.

Re: One united Ada policy for all Linux distributions?

[Dmitry A. Kazakov]

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

Re: One united Ada policy for all Linux distributions?

[Björn Persson]

Another difference, in addition to the ones Ludovic mentioned, is that the 
Debian policy requires static libraries in the -dev packages, while Fedora 
strongly discourages packaging static libraries and mandates that they be 
kept in -static packages, separate from the dynamic libraries in the -devel 
packages, if they really must be included.

Obviously we can't have one policy to rule them all, but we could certainly 
talk to each other and try to be compatible enough that we don't cause 
unnecessary trouble for users.

-- 
Bj�rn Persson
PGP key A88682FD

Re: One united Ada policy for all Linux distributions?

[Björn Persson]

Dmitry A. Kazakov wrote:

> Ideally gpr files should be installed where GPS,
> gprbuild, gnatmake could look after them. GNAT GPL's GPS does it in
> <GNAT-root>/lib/gnat. I think the policy should mandate a directory under
> /usr/lib or /usr/include for all gpr files rather than project-dependent
> directories.

The question of where to store .gpr files is actually rather complicated. 
The .gpr file for a library needs to point to architecture-specific library 
files, which makes the .gpr file itself architecture-specific if the 
location is hard-coded. For example, a multilib system may have a 32-bit 
/usr/lib/lib<library>.so with .ali files in /usr/lib/<library>/, and a 64-
bit /usr/lib64/lib<library>.so with .ali files in /usr/lib64/<library>/. It 
would then need two different .gpr files, one pointing to /usr/lib/<library> 
and the other to /usr/lib64/<library>. One might then try putting the .gpr 
files somewhere in /usr/lib* too, for example /usr/lib/gnat/<library>.gpr 
and /usr/lib64/gnat/<library>.gpr. That doesn't work however, because 
although Gnat can be configured to look for .gpr files in multiple 
directories, it will look in the same set of directories regardless of 
whether it's compiling for 32-bit or 64-bit mode, and use the first .gpr 
file with a matching name that it finds. If it finds the 64-bit 
<library>.gpr first, then compiling 32-bit binaries fails, and vice versa.

To solve this problem in Fedora I parameterize the .gpr files. There is a 
file named common.gpr which defines the variable Lib as either "lib" or 
"lib64" depending on an environment variable named HARDWARE_PLATFORM. 
HARDWARE_PLATFORM is defined by a snippet of shell script in 
/etc/profile.d/, and can be changed with the command "setarch". All the 
other .gpr files import common.gpr and use the variable Lib like this:

   for Library_Dir use "/usr/" & Common.Lib;
   for Library_ALI_Dir use "/usr/" & Common.Lib & "/<library>";

That makes the .gpr files architecture-independent. According to the 
Filesystem Hierarchy Standard they should then be somewhere under 
/usr/share. I keep them in /usr/lib/gnat however, because that's where Gnat 
looks for them (but not in /usr/lib64/gnat, only in /usr/lib/gnat). This is 
controlled by an RPM macro named _GNAT_project_dir, so if I were to move the 
.gpr files I would only need to change the macro and rebuild the packages.

-- 
Bj�rn Persson
PGP key A88682FD

Re: One united Ada policy for all Linux distributions?

[Dmitry A. Kazakov]

On Wed, 19 May 2010 15:23:51 +0200, Bj�rn Persson wrote:

> Another difference, in addition to the ones Ludovic mentioned, is that the 
> Debian policy requires static libraries in the -dev packages, while Fedora 
> strongly discourages packaging static libraries and mandates that they be 
> kept in -static packages, separate from the dynamic libraries in the -devel 
> packages, if they really must be included.

Isn't Debian's dev = Fedora's devel?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: One united Ada policy for all Linux distributions?

[Ludovic Brenta]

Dmitry A. Kazakov wrote on comp.lang.ada:
> On Wed, 19 May 2010 15:23:51 +0200, Björn Persson wrote:
> > Another difference, in addition to the ones Ludovic mentioned, is that the
> > Debian policy requires static libraries in the -dev packages, while Fedora
> > strongly discourages packaging static libraries and mandates that they be
> > kept in -static packages, separate from the dynamic libraries in the -devel
> > packages, if they really must be included.
>
> Isn't Debian's dev = Fedora's devel?

At the conceptual level, yes.  When you look into the details,
however, you find the differences that Björn and I mentioned.  Tu
summarize and in no particular order:

* Debian provides static libraries, Fedora doesn't.
* Fedora supports multilib, Debian doesn't (yet).
* Fedora provides sources in -debuginfo packages, Debian doesn't (in -
dbg packages).
* Debian installs .gpr files in /usr/share/ada/adainclude, Fedora in /
usr/lib/gnat.
* Debian understands the aliversion concept, Fedora doesn't (yet).

Whether or not these differences really matter, in practice, to a
third-party developer who builds their software against the packaged
libraries, I'm not sure.  I guess it would depend on the way the
developer chooses to build their software.

--
Ludovic Brenta.

Re: One united Ada policy for all Linux distributions?

[Björn Persson]

Dmitry A. Kazakov wrote:

> On Wed, 19 May 2010 15:23:51 +0200, Bj�rn Persson wrote:
> 
>> Another difference, in addition to the ones Ludovic mentioned, is that
>> the Debian policy requires static libraries in the -dev packages, while
>> Fedora strongly discourages packaging static libraries and mandates that
>> they be kept in -static packages, separate from the dynamic libraries in
>> the -devel packages, if they really must be included.
> 
> Isn't Debian's dev = Fedora's devel?

I'm not sure, but I think there are static libraries in all of Debian's -dev 
packages, not just in the Ada packages, so it's more like Fedora's -devel 
and -static combined. Fedora's -devel packages normally contain only shared 
libraries.

You can read the policy here:
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

-- 
Bj�rn Persson
PGP key A88682FD

Re: One united Ada policy for all Linux distributions?

[Stephen Leake]

Björn Persson <bjorn@xn--rombobjrn-67a.se> writes:

> Dmitry A. Kazakov wrote:
>
>> Ideally gpr files should be installed where GPS,
>> gprbuild, gnatmake could look after them. GNAT GPL's GPS does it in
>> <GNAT-root>/lib/gnat. I think the policy should mandate a directory under
>> /usr/lib or /usr/include for all gpr files rather than project-dependent
>> directories.
>
> The question of where to store .gpr files is actually rather complicated. 
> The .gpr file for a library needs to point to architecture-specific library 
> files, which makes the .gpr file itself architecture-specific if the 
> location is hard-coded. For example, a multilib system may have a 32-bit 
> /usr/lib/lib<library>.so with .ali files in /usr/lib/<library>/, and a 64-
> bit /usr/lib64/lib<library>.so with .ali files in /usr/lib64/<library>/. It 
> would then need two different .gpr files, one pointing to /usr/lib/<library> 
> and the other to /usr/lib64/<library>. 

I gather Debian will need to address this issue when we support multilib.

> One might then try putting the .gpr files somewhere in /usr/lib* too,
> for example /usr/lib/gnat/<library>.gpr and
> /usr/lib64/gnat/<library>.gpr. That doesn't work however, because
> although Gnat can be configured to look for .gpr files in multiple
> directories, it will look in the same set of directories regardless of
> whether it's compiling for 32-bit or 64-bit mode, and use the first
> .gpr file with a matching name that it finds. 

That's a bug, which I would expect to be fixed in a true multilib aware gnat. 

-- 
-- Stephe