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

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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.