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 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: <5ce2b9d6-478c-4a03-93c0-289e6559e199@l9g2000yqi.googlegroups.com> From: Stephen Leake Date: Tue, 20 Oct 2009 03:57:34 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) Cancel-Lock: sha1:80iJnS62ZnuMr0LGDB8VFH0Z/Bg= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: a08014add6d42e197caa725368 Xref: g2news2.google.com comp.lang.ada:8742 Date: 2009-10-20T03:57:34-04:00 List-Id: Ludovic Brenta 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 ~: >> >> ---- >> >> 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 = > 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 indicates a change in ali files due to a source chagne. If you put it after , 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--- libopentoken-3.1a-1-1-dev Here I've put before , 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 , and we can combine and into one field: : 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 and , leaving the full source version as: - Which is the original Debian policy scheme. The -dev package name would be: libLIBRARY- The build-depends expression would be a simple =, since any change is (treated as) an ali change: libLIBRARY (= -) 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. 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. > 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