udovic Brenta < XXXX@XXXXX.COM > writes:
Here is just such a proposal. You really need to read the relevant
parts of the Debian Ada policy  (sections 3 and 5) for this to make
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:
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
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 ~:
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 "to