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:

> Stephen Leake wrote on comp.lang.ada:
>> 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.
>
> Wow, that's a nice and systematic analysis. Thank you.
>
> [...]
>> 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.
> [...]
>> 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".

That '0' should be '1' under the rules I gave.

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

Ok.

> 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_ali = <empty>
> debian_ada_patch = 1
> debian_non_ada_patch = 1

That doesn't work; ~ must cover the non-Ada parts to get the
build-depends range correct. The correct range should be:

Build-Depends: libopentoken (>= A3.1a-1-1) libopentoken (< A3.1a-1-1~)

A change in <debian-ada-patch> indicates a change in ali files due to
a source chagne. If you put it after <upstream-non-ada>, then ali
files can change without failing the Build-Depends expression.

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

I must admit, the OpenToken version string strikes me as very
unweildy. But anything simpler does not satisfy all the requirements.
So this is a case of "make it as simple as possible, but no simpler".

The -dev package name is slightly better, since it leaves out the
non-Ada parts:

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

libopentoken-3.1a-1-1-dev

Here I've put <library-ali> before <debian-ada-patch>, since it should
be part of the upstream version, if upstream is binary.

However, the full source version, which appears in other places, still
needs all the fields. So this doesn't really avoid the problem; it
just hides it.

Note that this package name has more fields than in the current policy
draft; I think they are all necessary to accomplish the stated
purpose:

1) change in -dev name whenever an ali file changes

2) match upstream source version name

If we drop 2), as we allow for soversions, then the -dev version can
be a simple integer, but a _different_ integer than the soversion,
which would be another source of confusion. But maybe that is the
least confusing solution.

Hmm. If the upstream package is not binary, then the upstream version
does not include <library-ali>, and we can combine <debian-ada-patch>
and <library-ali> into one field: <debian-ada-patch-and-library-ali>:

libopentoken-3.1a-1-dev

That's better.

> In addition they are a burden on the maintainers worse than the
> solution I proposed. 

But only on the Ada maintainers; not the Debian release managers.
People who use Ada are used to satisfying demanding tools (just
getting things to compile is the hard part :).

And the work of separating out the Ada from non-Ada changes still has
to be done; the non-Ada changes are not explicitly documented in the
-dev name, but they are still there. In particular, they should be in
the full source version.

Upstream could have a policy of not making releases for non-Ada-only
changes, and Debian maintainers could also. That has the effect of
postponing the fixes for documentation and packaging bugs until an Ada
change is needed. Obviously, exceptions could be made for serious
bugs; we would incorporate the dependent package rebuild burden in the
definition of "serious". Then the two non-Ada fields could be dropped.
Then if upstream is not binary, we could also combine
<debian-ada-patch> and <library-ali>, leaving the full source version
as:

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

Which is the original Debian policy scheme. 

The -dev package name would be:

libLIBRARY<upstream-ada>-<debian-ada-patch-and-library-ali>

The build-depends expression would be a simple =, since any change is
(treated as) an ali change:

libLIBRARY (= <upstream-ada>-<debian-ada-patch-and-library-ali>)

Now the build-depends solution is slightly less burden on Ada package
maintainers (changing a build-depends expression is slightly easier
than changing a package name; the package name occurs in more places).

I'd be happy to adopt such a policy for OpenToken and GNADE; I suspect
most Ada packages would also.

Alternately, if the consensus is that version number in package name
is the solution I would use a simple integer for the -dev package name
version for OpenToken and GNADE.

If an upstream package has significant non-Ada parts, so it needs to
support releases with no Ada changes, but does not make binary
releases, they will not want to split their version number just to
support Debian binary releases. In that case, putting a simple integer
version in the -dev package name is the simplest solution.

<wild speculation> 

I think the only way to completely avoid a complex version number is
to drop binary distributions altogether. The Debian packages contain
only source, they can run GNAT to generate binaries as part of the
post-install script. The package installer can rerun the post-install
script whenever a library the package depends on changes.

That assumes people only submit packages that actually compile, and
that GNAT has no bugs. Maybe we are not there yet, but it is a goal.

</wild speculation>

> But let's hear other opinions :)
>
>> 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.
>
> 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.

Right. But we are using it for something else (although we allow for
this use as well). Maybe that's not as important as I think it is.

Not allowing multiple versions of -dev is the typical case. For
example, I don't intend to package OpenToken to allow for coexisting
versions; that invites bug reports on old versions, and requires fixes
for them; much too hard.

We should not have to abuse the multiple -dev mechanism for the
typical case.

>> We can work on adding a rule to lintian to help developers get the
>> 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.

Yes, that is a problem. Maybe if we use "ada" as a separator/label in
the version string? Or "ali" would serve equally well.

> Asking for such special treatment would definitely, IMHO, tarnish
> Ada's image.

Good point.

In summary, I guess I'm moving more towards accepting the version in
-dev package name solution, _if_ we allow it to be a simple integer
in appropriate cases (different from the soversion integer, and
unrelated to the upstream version).

The Debian Ada policy could allow either solution, as long as all the
consequences of the choice are clearly explained.

-- 
-- Stephe