From: Ludovic Brenta on
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.
From: Björn Persson on
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
From: Stephen Leake on
Björn Persson <bjorn(a)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