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

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

Post by Stephen Le » Tue, 20 Oct 2009 17:03:45


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 [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 "to
 
 
 

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

Post by Ludovic Br » Tue, 20 Oct 2009 17:31:36

tephen Leake wrote on comp.lang.ada:
>> > 5) Debian maintainer patches non-Ada source files (this includes> > ebian packaging files, such as 'control' and 'rules'), no>
> hanging the ali files.

Wow, that's a nice and systematic analysis. Thank you.

[..>]
> If we use the version number in build dependencies, we need >n
> 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 >t
> the end, so they can be covered by a single >: >>< > ---- >>
> This does not follow the Debian policy, since there is an upstre>m
> part in the middle of the Debian part, but it has a valid rational>,
> so I think we should just use it, or get a waiver, or propose a mod >o
> the Debian policy.
[..>]
> As an example, the OpenToken upstream version would be "A3.1a-N2" (A>a
> 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".

We could use a separator different from '-' so as not to violate the
Debian Policy as much and we do not need a change to the Policy. Also,
let's put the two Debian-specific parts after the '-'. For example
OpenToken would be:

libopentoken-dev (=3.1a+2-1+1)

where:
upstream_ada = 3.1a
upstream_non_ada = 2
library_al< =
debian_ada_patch = 1
debian_non_ada_patch = 1>
> In summary, I don't see sufficient advantage to putting the versi>n
> number in the -dev package name. The only advantage I see is it forc>s
> developers to get the dependencies right. It has the significa>t
> disadvantages of the extra burden on Debian release managers, and t>e
> additional tarnishing of the Ada image.

I personally think the complicated version numbers would contribute to
such tarnishing just as much as having part of the version number in
the package name. In addition they are a burden on the maintainers
worse than the solution I proposed. But let's hear other opinions :)>
> The version numbering scheme proposed here violates Debian policy, b>t
> I see including the version number in the -dev package name as a wor>e
> violation of Debian policy.

Version numbers in the names of packages do not violate Debian Policy;
they are allowed specifically to allow several versions of a -dev
package to be installed simultaneously. e.g. see libboost1.40-all-dev,
currently in testing.>
> We can work on adding a rule to lintian to help developers get t>e
> build dependencies right.

I honestly don't think a rule in lintian would be that easy to
formulate or implement; for starters, it would have to distinguish
packages built from Ada sources from those build from other languages.
Asking for such special treatment would definitely, IMHO, tarnish
Ada's image.

Ludovic Brenta.

 
 
 

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

Post by Ludovic Br » Tue, 20 Oct 2009 22:28:47


I also dislike it :)


I think you'd need to take this proposal up to the maintainers of dpkg
and propose a standard set of attributes and the associated rules for
taking these attributes into account when comparing package versions.
Also, remember that there can be only one package with a given file
name; currently Debian encodes the version in the file name so that
archives can carry multiple versions of a package at the same time
(e.g. stable, testing and unstable).

Your solution seems theoretically sound to me, except for the fact
that it is only needed for Ada and a couple other languages like OCaml
that care about consistency between source and binaries across the
entire closure of a program. Asking for dpkg to support this solution,
potentially breaking backward compatibility with archives and making
in-place upgrades problematic, all for the sole benefit of these few
languages seems politically suicidal :)

So far, I still think that encoding the ".ali" version number in the
name of the -dev package (e.g. libopentoken3.1a-dev) is the least ugly
and least impractical solution.

Ludovic Brenta.
 
 
 

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

Post by Ludovic Br » Wed, 21 Oct 2009 00:47:59

Georg Bauhaus wrote in comp.lang.ada:

Whatever solution we choose has to apply to each package individually;
the GNAT version numbers have nothing to do with the version numbers
of other packages, except that if the .ali files in GNAT change, all
Ada packages need to be rebuilt, thereby producing new .ali files of
their own, with a version number of their own.


Yes, "ali" as a prefix would be acceptable, e.g.

libopentoken-dev (= 3.1a+2-1ali1)

that would become libopentoken-dev (= 3.1a+2-1ali1squeeze1) if ever
there is an upload to stable for a security fix, or libopentoken-dev
(= 3.1a+2-1ali1.1) if there is a non-maintainer upload. And then
Ubuntu would probably add its markings on top of that, too :)

Luckily, there is no character in Toy Story named Ali, so there will
not be a clash between the code-name of a Debian release and the
prefixes :)

Ludovic Brenta.