From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,47bc8b783af4aa38 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" References: From: Stephen Leake Date: Mon, 19 Oct 2009 04:03:45 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) Cancel-Lock: sha1:GvWUTA6LRLjYJo2m4Avn79kwz+w= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 371fa4adc1d3ce197caa718090 Xref: g2news2.google.com comp.lang.ada:8726 Date: 2009-10-19T04:03:45-04:00 List-Id: Ludovic Brenta 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: Each part is incremented separately as the sources and the libraries they depend on evolve. and are reset to 1 when changes, is reset to 1 when 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 part. Note that 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 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[-]-- 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 ~: ---- 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 and 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