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

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

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.