Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze"

[Stephen Leake <stephen_leake@stephe-leake.org>]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> The biggest change to the Policy is that it now requires that every
> - dev package for an Ada library include the version number of the
> library in its name. For example, "libaws-dev" should become
> "libaws2.5-dev" to comply with this policy. The draft document
> explains the reasons behind this decision in great detail. However,
> if you can propose a scheme that avoids the need for this change,
> please speak up.

Here is just such a proposal. You really need to read the relevant
parts of the Debian Ada policy [2] (sections 3 and 5) for this to make
sense.

[2] http://people.debian.org/~lbrenta/debian-ada-policy4draft1.pdf

For the purposes of this discussion, there are five reasons a Debian
package source version needs to change:

1) The upstream Ada source changes, changing the ali files.

2) The upstream non-Ada source changes, not changing the ali files.

3) Debian maintainer patches Ada source files, changing the ali files.

4) A library the package depends on changes its ali files; Debian
   maintainer recompiles, changing the ali files. This includes the
   case of a GNAT compiler version change.

5) Debian maintainer patches non-Ada source files (this includes
   Debian packaging files, such as 'control' and 'rules'), not
   changing the ali files.


To handle all of these changes orthogonally, we should use a version
number that contains all of these parts, in some order:

<upstream-ada>
<upstream-non-ada>
<library-ali>
<debian-ada-patch>
<debian-non-ada-patch>

Each part is incremented separately as the sources and the libraries
they depend on evolve. <library-ali> and <debian-ada-patch> are reset
to 1 when <upstream-ada> changes, <debian-non-ada-patch> is reset to 1
when <upstream-non-ada> changes.

If the upstream distribution is binary, they have the same library ali
issues that Debian does, so the upstream source version should include
the <library-ali> part.

Note that <library-ali> may be different between the Debian package
and the upstream package; it depends on what library ali changes each
has reacted to, so there's a race condition. 

If the upstream distribution is _not_ binary, the upstream source
version should not include the <library-ali> part.

If we put the version number in the package name, the package name has
to change in cases 1, 3, and 4. That means the package name looks
like:

libLIBRARY[-]<upstream-ada>-<debian-ada-patch>-<library-ali>

The order of the version number parts is not important here, since we
are not matching or sorting on it. 

If we use the version number in build dependencies, we need an
expression that allows both non-Ada parts to change without causing a
FTBFS. To do that, we need all the parts that are allowed to change at
the end, so they can be covered by a single ~:

<upstream-ada>-<debian-ada-patch>-<library-ali>-<upstream-non-Ada>-<debian-non-ada-patch>

This does not follow the Debian policy, since there is an upstream
part in the middle of the Debian part, but it has a valid rationale,
so I think we should just use it, or get a waiver, or propose a mod to
the Debian policy.

Note that both choices (version number in -dev package name, or in
build dependency) have the same requirements on the upstream version
number; it must separate the Ada, non-Ada, and library-ali parts.

We can request that all upstream Ada authors adopt this scheme. If
they don't, the worst case is that the <upstream-ada> and
<upstream-non-Ada> are lumped together. Then we either have to live
with the extra repackaging due to non-Ada upstream changes, or not use
the upstream version in the Debian version at all (ie, define the
upstream version as "too weird"). For packages that are mostly Ada, we
can hope that purely non-Ada upstream changes will be rare.

As an example, the OpenToken upstream version would be "A3.1a-N2" (Ada
part 3.1a, non-Ada part 2, no library-ali part since it is not a
binary distribution), and the Debian version "A3.1a-0-1-N2-1".


In summary, I don't see sufficient advantage to putting the version
number in the -dev package name. The only advantage I see is it forces
developers to get the dependencies right. It has the significant
disadvantages of the extra burden on Debian release managers, and the
additional tarnishing of the Ada image.

The version numbering scheme proposed here violates Debian policy, but
I see including the version number in the -dev package name as a worse
violation of Debian policy.

We can work on adding a rule to lintian to help developers get the
build dependencies right.

-- 
-- Stephe