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 Georg Bauh » Tue, 20 Oct 2009 21:11:47

Ludovic Brenta schrieb:

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.

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:

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.

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

Post by Georg Bauh » Wed, 21 Oct 2009 00:16:27

Ludovic Brenta schrieb:

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.

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


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

Post by Stephen Le » Wed, 21 Oct 2009 16:57:34

udovic Brenta < XXXX@XXXXX.COM > writes:

>> hanging the ali file>. >>
> Wow, that's a nice and systematic analysis. Thank yo>. >>
> [..>>
>> If we use the version number in build dependencies, we need >>
>> expression that allows both non-Ada parts to change without causing>>
>> FTBFS. To do that, we need all the parts that are allowed to change >>
>> the end, so they can be covered by a single >>
>> This does not follow the Debian policy, since there is an upstre>>
>> 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 >>
>> the Debian polic>.
> [..>>
>> As an example, the OpenToken upstream version would be "A3.1a-N2" (A>>
>> part 3.1a, non-Ada part 2, no library-ali part since it is not>>
>> 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 t>e
> 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 '-'. F>r
> example OpenToken would b>: >>
> libopentoken-dev (=3.1a+2-1+>) >>
> wher>:
> upstream_ada = 3.>a
> upstream_non_ada =>2
> library_al< =
> 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: libopentok>n (>= A3.1a-1-1) libopentok<n (< A3.1a-1-1~)

A change<in indicates a change in ali files due to
a source chagne. If you put it af<er , then ali
files can change without failing the Build-Depends expression.>>
>> In summary, I don't see sufficient advantage to putting the versi>>
>> number in the -dev package name. The only advantage I see is it forc>>
>> developers to get the dependencies right. It has the significa>>
>> disadvantages of the extra burden on Debian release managers, and t>>
>> additional tarnishing of the Ada imag>. >>
> I personally think the complicated version numbers would contribute >o
> such tarnishing just as much as having part of the version number >n
> 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:



Here I've <ut bef<re , 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

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 _diff