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

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

[Ludovic Brenta]

Over the past month, Stephe Leake and I have put in a lot of effort
towards updating the Debian Policy for Ada[1].  We think we have
reached
a state where the new policy is almost ready and so I have published a
draft[2] of the next edition.  I would like to call upon every
interested party to read the new draft and send us their comments.

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

The Debian Policy for Ada is what sets Debian's support for Ada apart
from the rest.  It has served us well over the past three releases of
Debian: 3.1 "Sarge", released in June 2005; 4.0 "Etch" in April 2007;
and 5.0 "Lenny" in February 2009.

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.

In related news, the Debian release managers have just proposed[3] a
freeze in March 2010; this means that the maintainers of Ada packages
now have 5 months to migrate all the packages to gnat-4.4.  This
migration will start in earnest.  As usual, I reiterate my call for
contributions: if you use one of the Ada packages in Debian, please
consider helping the maintainer with the transition.

[3] http://lists.debian.org/debian-devel-announce/2009/10/msg00002.html

Happy hacking!

--
Ludovic Brenta.

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

[Stephen Leake]

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

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

[Ludovic Brenta]

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

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

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

> 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.
Asking for such special treatment would definitely, IMHO, tarnish
Ada's image.

--
Ludovic Brenta.

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

[Georg Bauhaus]

Ludovic Brenta schrieb:
> Stephen Leake wrote on comp.lang.ada:

> [...]
>> 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".
> 
> 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)

Any such expression of the versioning scheme would, sooner or
later, drive package users up several walls IMHO, after tearing
some hair out. Here is why it seems inacceptable:

(1) The symbolism, using positional notation and always multiply
overloaded punctuation in those tail pictures, is anything
but obvious: it requires learning a specific bureaucratic formalism++.
Such information should instead be hidden behind some interface.
If not, there is service inversion.  The package user
(client) will have to deal with *internal* data of the package
handling service.

(2) Users would wonder from what *time-dependent* semantics
the *implicit* meaning of the suffix is to be deduced.  Makes me
think that Ada programmers have better things to do.  After all,
they are used to fewer exegetic efforts at deciphering symbolism.

Solution:
Can someone important please mention the availability
of *extended* *file* *attributes*---BTW in *both* file systems
(including UDF) and in standard archive formats such as zip and
tar (hence easily available to deb) !
With extended file attributes the above information can be
coded almost like this:

> upstream_ada = 3.1a
> upstream_non_ada = 2
> library_ali = <empty>
> debian_ada_patch = 1
> debian_non_ada_patch = 1

Do you see the named notation, the XML attributes, and the
property settings?  :-)  Package handling tools would not
need to have yet another ad hoc, ever changing parser for file
name infixes.  Instead, they could use the library routines for
extended file attribute handling.

Extended file attributes are too revolutionary?
THEY ARE NOT!  Good old stuff.
Hey, Debian could have something to show off.
And help save us from even more idiosyncracy.

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

[Ludovic Brenta]

Georg Bauhaus wrote:
> Ludovic Brenta schrieb:
> > libopentoken-dev (=3.1a+2-1+1)
>
> Any such expression of the versioning scheme would, sooner or
> later, drive package users up several walls IMHO, after tearing
> some hair out. Here is why it seems inacceptable:

I also dislike it :)

> Solution:
> Can someone important please mention the availability
> of *extended* *file* *attributes*---BTW in *both* file systems
> (including UDF) and in standard archive formats such as zip and
> tar (hence easily available to deb) !
> With extended file attributes the above information can be
> coded almost like this:
>
> > upstream_ada = 3.1a
> > upstream_non_ada = 2
> > library_ali = <empty>
> > debian_ada_patch = 1
> > debian_non_ada_patch = 1
>
> Do you see the named notation, the XML attributes, and the
> property settings?  :-)  Package handling tools would not
> need to have yet another ad hoc, ever changing parser for file
> name infixes.  Instead, they could use the library routines for
> extended file attribute handling.

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.

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

[Georg Bauhaus]

Ludovic Brenta schrieb:
> 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 :)

Yes, a change of Unixoids so radical as to be later than the
70s is asking for political noise.  ;-)  That's why extended
attributes need someone whose political statements are being
considered, or else a complete working solution that leaves
no one behind: the two approaches (names, extented attributes)
need not exclude each other.
Backwards compatibility should thus be possible.

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

I like Stephen's prefix characters because the resulting numbers
do not overlap former GNAT version numbers like 3.1a
(vs 3.1p)---which is not what is meant in your
example, I think.  Maybe just use "ali"?  The
substring "ubuntu" seems acceptable in another world
of deb package maintenance, so maybe "ali" isn't be
asking too much of the naming authorities.
It sure requesting a nod to less than using Linux file
system features :-)

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

[Ludovic Brenta]

Georg Bauhaus wrote in comp.lang.ada:
> Ludovic Brenta schrieb:
>> 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.
>
> I like Stephen's prefix characters because the resulting numbers
> do not overlap former GNAT version numbers like 3.1a
> (vs 3.1p)---which is not what is meant in your
> example, I think.

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.

>  Maybe just use "ali"?  The
> substring "ubuntu" seems acceptable in another world
> of deb package maintenance, so maybe "ali" isn't be
> asking too much of the naming authorities.
> It sure requesting a nod to less than using Linux file
> system features :-)

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.

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

[Stephen Leake]

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

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

[Ludovic Brenta]

Stephen Leake wrote on comp.lang.ada:
> 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>)

No, that would be

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

without a version number.

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

Actually I think the opposite is true: the if you build-depend on a -
dev package,
getting its name right is easy (copy and paste). In contrast, getting
the version number *range* right is difficult, especially if the
version numbering scheme is very complex.

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

e.g.

source: opentoken (=4.0-1)
binary: libopentoken0-dev (=4.0-1)
binary: libopentoken5 (=4.0-1)
binary: libopentoken5-dbg (=4.0-1)
binary: libopentoken0-dev (=4.0-1)

?

Yes, I like that.

--
Ludovic Brenta.

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

[Ludovic Brenta]

Stephe Leake and I are now satisfied with our latest changes to the
Debian Policy for Ada.  I have now published it[1] and will commence
the transition of all Ada package to this new policy; this includes
moving to gnat-4.4 as the Ada compiler and adding "aliversion" numbers
to all -dev package names.

[1] http://people.debian.org/~lbrenta/debian-ada-policy.html
http://people.debian.org/~lbrenta/debian-ada-policy.pdf
http://people.debian.org/~lbrenta/debian-ada-policy.txt
http://people.debian.org/~lbrenta/debian-ada-policy.info
http://people.debian.org/~lbrenta/debian-ada-policy.texi

This new policy applies to the release of Debian currently in
development, 6.0 "Squeeze".  The policy for the current release, 5.0
"Etch", is still available[2].

[2] http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.html
http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.pdf
http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.txt
http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.info
http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.texi

--
Ludovic Brenta.

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

[Niklas Holsti]

Ludovic Brenta wrote:
> ...
> This new policy applies to the release of Debian currently in
> development, 6.0 "Squeeze".  The policy for the current release, 5.0
> "Etch", is still available[2].

Isn't the current "stable" Debian release called "Lenny"?

The links that you gave (below) don't work with "etch", but do work if 
"etch" is changed to "lenny".

> [2] http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.html
> http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.pdf
> http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.txt
> http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.info
> http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.texi

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

[Ludovic Brenta]

Niklas Holsti wrote:
> Ludovic Brenta wrote:
>> ...
>> This new policy applies to the release of Debian currently in
>> development, 6.0 "Squeeze".  The policy for the current release, 5.0
>> "Etch", is still available[2].
>
> Isn't the current "stable" Debian release called "Lenny"?
>
> The links that you gave (below) don't work with "etch", but do work if
> "etch" is changed to "lenny".
>
>> [2]http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.html
>>http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.pdf
>>http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.txt
>>http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.info
>>http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.texi

Thanks. Yes, that was a thinko on my part.  The correct links are
therefore:

[2]http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.html
http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.pdf
http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.txt
http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.info
http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.texi

--
Ludovic Brenta.