* RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" @ 2009-10-18 17:36 Ludovic Brenta 2009-10-19 8:03 ` Stephen Leake 2009-10-26 18:54 ` ANN: " Ludovic Brenta 0 siblings, 2 replies; 12+ messages in thread From: Ludovic Brenta @ 2009-10-18 17:36 UTC (permalink / raw) Over the past month, Stephe Leake and I have put in a lot of effort towards updating the Debian Policy for Ada[1]. We think we have reached a state where the new policy is almost ready and so I have published a draft[2] of the next edition. I would like to call upon every interested party to read the new draft and send us their comments. [1] http://people.debian.org/~lbrenta/debian-ada-policy.pdf [2] http://people.debian.org/~lbrenta/debian-ada-policy4draft1.pdf The Debian Policy for Ada is what sets Debian's support for Ada apart from the rest. It has served us well over the past three releases of Debian: 3.1 "Sarge", released in June 2005; 4.0 "Etch" in April 2007; and 5.0 "Lenny" in February 2009. 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. In related news, the Debian release managers have just proposed[3] a freeze in March 2010; this means that the maintainers of Ada packages now have 5 months to migrate all the packages to gnat-4.4. This migration will start in earnest. As usual, I reiterate my call for contributions: if you use one of the Ada packages in Debian, please consider helping the maintainer with the transition. [3] http://lists.debian.org/debian-devel-announce/2009/10/msg00002.html Happy hacking! -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-18 17:36 RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" Ludovic Brenta @ 2009-10-19 8:03 ` Stephen Leake 2009-10-19 8:31 ` Ludovic Brenta 2009-10-26 18:54 ` ANN: " Ludovic Brenta 1 sibling, 1 reply; 12+ messages in thread From: Stephen Leake @ 2009-10-19 8:03 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> 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: <upstream-ada> <upstream-non-ada> <library-ali> <debian-ada-patch> <debian-non-ada-patch> Each part is incremented separately as the sources and the libraries they depend on evolve. <library-ali> and <debian-ada-patch> are reset to 1 when <upstream-ada> changes, <debian-non-ada-patch> is reset to 1 when <upstream-non-ada> 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 <library-ali> part. Note that <library-ali> 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 <library-ali> 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[-]<upstream-ada>-<debian-ada-patch>-<library-ali> 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 ~: <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. 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 <upstream-ada> and <upstream-non-Ada> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-19 8:03 ` Stephen Leake @ 2009-10-19 8:31 ` Ludovic Brenta 2009-10-19 12:11 ` Georg Bauhaus 2009-10-20 7:57 ` Stephen Leake 0 siblings, 2 replies; 12+ messages in thread From: Ludovic Brenta @ 2009-10-19 8:31 UTC (permalink / raw) 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 ~: > > <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) where: upstream_ada = 3.1a upstream_non_ada = 2 library_ali = <empty> debian_ada_patch = 1 debian_non_ada_patch = 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. 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. In addition they are a burden on the maintainers worse than the solution I proposed. 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. > 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. Asking for such special treatment would definitely, IMHO, tarnish Ada's image. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-19 8:31 ` Ludovic Brenta @ 2009-10-19 12:11 ` Georg Bauhaus 2009-10-19 13:28 ` Ludovic Brenta 2009-10-20 7:57 ` Stephen Leake 1 sibling, 1 reply; 12+ messages in thread From: Georg Bauhaus @ 2009-10-19 12:11 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-19 12:11 ` Georg Bauhaus @ 2009-10-19 13:28 ` Ludovic Brenta 2009-10-19 15:16 ` Georg Bauhaus 0 siblings, 1 reply; 12+ messages in thread From: Ludovic Brenta @ 2009-10-19 13:28 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-19 13:28 ` Ludovic Brenta @ 2009-10-19 15:16 ` Georg Bauhaus 2009-10-19 15:47 ` Ludovic Brenta 0 siblings, 1 reply; 12+ messages in thread From: Georg Bauhaus @ 2009-10-19 15:16 UTC (permalink / raw) Ludovic Brenta schrieb: > 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 :) 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. > 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. 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 :-) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-19 15:16 ` Georg Bauhaus @ 2009-10-19 15:47 ` Ludovic Brenta 0 siblings, 0 replies; 12+ messages in thread From: Ludovic Brenta @ 2009-10-19 15:47 UTC (permalink / raw) Georg Bauhaus wrote in comp.lang.ada: > Ludovic Brenta schrieb: >> 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. > > 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. Whatever solution we choose has to apply to each package individually; the GNAT version numbers have nothing to do with the version numbers of other packages, except that if the .ali files in GNAT change, all Ada packages need to be rebuilt, thereby producing new .ali files of their own, with a version number of their own. > 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 :-) Yes, "ali" as a prefix would be acceptable, e.g. libopentoken-dev (= 3.1a+2-1ali1) that would become libopentoken-dev (= 3.1a+2-1ali1squeeze1) if ever there is an upload to stable for a security fix, or libopentoken-dev (= 3.1a+2-1ali1.1) if there is a non-maintainer upload. And then Ubuntu would probably add its markings on top of that, too :) Luckily, there is no character in Toy Story named Ali, so there will not be a clash between the code-name of a Debian release and the prefixes :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-19 8:31 ` Ludovic Brenta 2009-10-19 12:11 ` Georg Bauhaus @ 2009-10-20 7:57 ` Stephen Leake 2009-10-20 9:42 ` Ludovic Brenta 1 sibling, 1 reply; 12+ messages in thread From: Stephen Leake @ 2009-10-20 7:57 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> 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 ~: >> >> <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". 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 = <empty> > 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 <debian-ada-patch> indicates a change in ali files due to a source chagne. If you put it after <upstream-non-ada>, 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-<upstream-ada>-<library-ali>-<debian-ada-patch> libopentoken-3.1a-1-1-dev Here I've put <library-ali> before <debian-ada-patch>, 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 <library-ali>, and we can combine <debian-ada-patch> and <library-ali> into one field: <debian-ada-patch-and-library-ali>: 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 <debian-ada-patch> and <library-ali>, leaving the full source version as: <upstream-ada>-<debian-ada-patch-and-library-ali> Which is the original Debian policy scheme. The -dev package name would be: libLIBRARY<upstream-ada>-<debian-ada-patch-and-library-ali> The build-depends expression would be a simple =, since any change is (treated as) an ali change: libLIBRARY (= <upstream-ada>-<debian-ada-patch-and-library-ali>) 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. <wild speculation> 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. </wild speculation> > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-20 7:57 ` Stephen Leake @ 2009-10-20 9:42 ` Ludovic Brenta 0 siblings, 0 replies; 12+ messages in thread From: Ludovic Brenta @ 2009-10-20 9:42 UTC (permalink / raw) Stephen Leake wrote on comp.lang.ada: > The build-depends expression would be a simple =, since any change is > (treated as) an ali change: > > libLIBRARY (= <upstream-ada>-<debian-ada-patch-and-library-ali>) No, that would be libLIBRARY-<upstream-ada>-<debian-ada-patch-and-library-ali>-dev without a version number. > 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). Actually I think the opposite is true: the if you build-depend on a - dev package, getting its name right is easy (copy and paste). In contrast, getting the version number *range* right is difficult, especially if the version numbering scheme is very complex. > 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. e.g. source: opentoken (=4.0-1) binary: libopentoken0-dev (=4.0-1) binary: libopentoken5 (=4.0-1) binary: libopentoken5-dbg (=4.0-1) binary: libopentoken0-dev (=4.0-1) ? Yes, I like that. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 12+ messages in thread
* ANN: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-18 17:36 RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" Ludovic Brenta 2009-10-19 8:03 ` Stephen Leake @ 2009-10-26 18:54 ` Ludovic Brenta 2009-10-26 20:21 ` Niklas Holsti 1 sibling, 1 reply; 12+ messages in thread From: Ludovic Brenta @ 2009-10-26 18:54 UTC (permalink / raw) Stephe Leake and I are now satisfied with our latest changes to the Debian Policy for Ada. I have now published it[1] and will commence the transition of all Ada package to this new policy; this includes moving to gnat-4.4 as the Ada compiler and adding "aliversion" numbers to all -dev package names. [1] http://people.debian.org/~lbrenta/debian-ada-policy.html http://people.debian.org/~lbrenta/debian-ada-policy.pdf http://people.debian.org/~lbrenta/debian-ada-policy.txt http://people.debian.org/~lbrenta/debian-ada-policy.info http://people.debian.org/~lbrenta/debian-ada-policy.texi This new policy applies to the release of Debian currently in development, 6.0 "Squeeze". The policy for the current release, 5.0 "Etch", is still available[2]. [2] http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.html http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.pdf http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.txt http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.info http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.texi -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-26 18:54 ` ANN: " Ludovic Brenta @ 2009-10-26 20:21 ` Niklas Holsti 2009-10-26 22:55 ` Ludovic Brenta 0 siblings, 1 reply; 12+ messages in thread From: Niklas Holsti @ 2009-10-26 20:21 UTC (permalink / raw) Ludovic Brenta wrote: > ... > This new policy applies to the release of Debian currently in > development, 6.0 "Squeeze". The policy for the current release, 5.0 > "Etch", is still available[2]. Isn't the current "stable" Debian release called "Lenny"? The links that you gave (below) don't work with "etch", but do work if "etch" is changed to "lenny". > [2] http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.html > http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.pdf > http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.txt > http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.info > http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.texi -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: ANN: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" 2009-10-26 20:21 ` Niklas Holsti @ 2009-10-26 22:55 ` Ludovic Brenta 0 siblings, 0 replies; 12+ messages in thread From: Ludovic Brenta @ 2009-10-26 22:55 UTC (permalink / raw) Niklas Holsti wrote: > Ludovic Brenta wrote: >> ... >> This new policy applies to the release of Debian currently in >> development, 6.0 "Squeeze". The policy for the current release, 5.0 >> "Etch", is still available[2]. > > Isn't the current "stable" Debian release called "Lenny"? > > The links that you gave (below) don't work with "etch", but do work if > "etch" is changed to "lenny". > >> [2]http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.html >>http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.pdf >>http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.txt >>http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.info >>http://people.debian.org/~lbrenta/5.0-etch/debian-ada-policy.texi Thanks. Yes, that was a thinko on my part. The correct links are therefore: [2]http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.html http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.pdf http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.txt http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.info http://people.debian.org/~lbrenta/5.0-lenny/debian-ada-policy.texi -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-10-26 22:55 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-10-18 17:36 RFC: Debian Policy for Ada, Fourth Edition for Debian 6.0 "Squeeze" Ludovic Brenta 2009-10-19 8:03 ` Stephen Leake 2009-10-19 8:31 ` Ludovic Brenta 2009-10-19 12:11 ` Georg Bauhaus 2009-10-19 13:28 ` Ludovic Brenta 2009-10-19 15:16 ` Georg Bauhaus 2009-10-19 15:47 ` Ludovic Brenta 2009-10-20 7:57 ` Stephen Leake 2009-10-20 9:42 ` Ludovic Brenta 2009-10-26 18:54 ` ANN: " Ludovic Brenta 2009-10-26 20:21 ` Niklas Holsti 2009-10-26 22:55 ` Ludovic Brenta
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox