One united Ada policy for all Linux distributions?
in [ADA]
|
From: Ludovic Brenta on 17 May 2010 06:29 Dmitry A. Kazakov wrote on comp.lang.ada: > is it possible to have one united Ada policy for all Linux distributions? > > Linux Ada community is small, all people are known. Can't we use this as an > advantage here? I would love to see that happen but unfortunately the Ada *distribution maintainer* community is even smaller than the Linux Ada community. The current state, as I see it: * several people on the GNU Ada project[1] work on SuSE, Mac OS X and a couple others. Unfortunately their work is not part of the official distributions they target, i.e. they are "outsiders". * one person would like to emulate the Debian policy for Ada on FreeBSD[2]. * one person would like to emulate the Debian policy for Ada on AuroraUX[3]. * one person works on Gentoo. No recent news on comp.lang.ada however. * one person works on Fedora and has made two packages. * four maintainers plus a couple of occasional contributors are active on Debian; there is a snowball effect as these maintainers pool resources and build on the existing, solid foundation. * several users such as yourself have recently switched to Debian because of the better support for Ada. This adds to the snowball effect as these users can contribute useful bug reports and suggestions, as you just did. [1] http://gnuada.sourceforge.net/ [2] http://lists.freebsd.org/pipermail/freebsd-ports/2009-November/057661.html [3] http://forums.auroraux.org/viewtopic.php?f=12&t=24 -- Ludovic Brenta.
From: Ludovic Brenta on 18 May 2010 05:32 Further musings on this hypothetical "unified" policy: - The policy would have to mandate package names so they are the same across distributions. - The policy would have to mandate a minimal set of packages that must be provided in all distributions. - For this, the policy for package names might conflict with distribution-wide policies about package names. For example, in Debian, detached debugging symbols must be in packages with names ending with -dbg while Fedora uses -debuginfo instead. Also the Fedora -debuginfo packages must contain the sources while the Debian - dbg packages may not. - The package names must change when the ALI files change (the Debian Policy for Ada explains why in detail; this is not specific to Debian but is a consequence of the Ada language definition, so must apply to all distributions). - The release cycles are different for all distributions. Therefore, at any point in time, each distribution would provide a different collection of the compiler and of all libraries, using different package names. This may or may not have an impact on user programs and compilation commands. - Therefore, a grand unified, cross-distribution policy for Ada is theoretically impossible; only a minimalistic policy would be possible. - The closest thing we have currently is GNAT GPL Edition: it is cross- platform and minimalistic (compiler, IDE, some tools and a small selection of libraries in source-only form). -- Ludovic Brenta.
From: Dmitry A. Kazakov on 18 May 2010 06:04 On Tue, 18 May 2010 02:32:40 -0700 (PDT), Ludovic Brenta wrote: > Further musings on this hypothetical "unified" policy: > > - The policy would have to mandate package names so they are the same > across distributions. Yes > - The policy would have to mandate a minimal set of packages that must > be provided in all distributions. Yes > - For this, the policy for package names might conflict with > distribution-wide policies about package names. For example, in > Debian, detached debugging symbols must be in packages with names > ending with -dbg while Fedora uses -debuginfo instead. Also the > Fedora -debuginfo packages must contain the sources while the Debian - > dbg packages may not. Naming of the derived packages is IMO of minor importance. It is OK to have gtkada-dev and gtkada-devel, so long "gtkada" is same. > - The package names must change when the ALI files change (the Debian > Policy for Ada explains why in detail; this is not specific to Debian > but is a consequence of the Ada language definition, so must apply to > all distributions). Do you mean version suffix? > - The release cycles are different for all distributions. Therefore, > at any point in time, each distribution would provide a different > collection of the compiler and of all libraries, using different > package names. This may or may not have an impact on user programs > and compilation commands. Yes, when using plain gnatmake with -I, -L stuff. (Who cares?) No, when project files used. The project file names must be invariant. E.g. gtkada.gpr. Ideally gpr files should be installed where GPS, gprbuild, gnatmake could look after them. GNAT GPL's GPS does it in <GNAT-root>/lib/gnat. I think the policy should mandate a directory under /usr/lib or /usr/include for all gpr files rather than project-dependent directories. If we wanted to introduce versioning (coexistence in Debian policy terms?), we could hang version suffixes on the gpr's directory, rather than on gpr files. The suffix will follow GNAT releases. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Ludovic Brenta on 18 May 2010 06:19 Dmitry A. Kazakov wrote on comp.lang.ada: > On Tue, 18 May 2010 02:32:40 -0700 (PDT), Ludovic Brenta wrote: >> - The package names must change when the ALI files change (the Debian >> Policy for Ada explains why in detail; this is not specific to Debian >> but is a consequence of the Ada language definition, so must apply to >> all distributions). > > Do you mean version suffix? I mean the "aliversion" which must be somewhere in the package name, e.g. in libgtkada2.14.2-dev the aliversion is 2.14.2. It does not have to be a suffix; it only has to be present. >> - The release cycles are different for all distributions. Therefore, >> at any point in time, each distribution would provide a different >> collection of the compiler and of all libraries, using different >> package names. This may or may not have an impact on user programs >> and compilation commands. > > Yes, when using plain gnatmake with -I, -L stuff. (Who cares?) > > No, when project files used. The project file names must be invariant. E.g. > gtkada.gpr. Ideally gpr files should be installed where GPS, gprbuild, > gnatmake could look after them. GNAT GPL's GPS does it in > <GNAT-root>/lib/gnat. I think the policy should mandate a directory under > /usr/lib or /usr/include for all gpr files rather than project-dependent > directories. Debian uses the proposed "standard": /usr/share/ada/adainclude and patches libgnatprj.so to look there for project files. libgnatprj.so is shared between all GNAT tools and GPS and, in the future, gprbuild. (in the mean time, gprbuild is patched too). > If we wanted to introduce versioning (coexistence in Debian policy terms?), > we could hang version suffixes on the gpr's directory, rather than on gpr > files. The suffix will follow GNAT releases. That would be too restrictive; it would not allow you to have e.g. two versions of a library with the same compiler. This is no better than the GNAT GPL distribution as you noted. So the versioning would have to use the aliversion in the names of the .gpr files, possibly with a versionless symlink to the default versioned project file, e.g.: /usr/share/ada/adainclude/gtkada2.14.2.gpr /usr/share/ada/adainclude/gtkada2.18.gpr /usr/share/ada/adainclude/gtkada.gpr -> gtkada2.14.2.gpr -- Ludovic Brenta.
From: Dmitry A. Kazakov on 18 May 2010 08:16 On Tue, 18 May 2010 03:19:36 -0700 (PDT), Ludovic Brenta wrote: > Dmitry A. Kazakov wrote on comp.lang.ada: >> If we wanted to introduce versioning (coexistence in Debian policy terms?), >> we could hang version suffixes on the gpr's directory, rather than on gpr >> files. The suffix will follow GNAT releases. > > That would be too restrictive; it would not allow you to have e.g. two > versions of a library with the same compiler. Why? Each GNAT (gnatmake, gprbuild) would search its project directory first. It should be no different from the way the standard library ads files are handled - transparently to the user. > This is no better than > the GNAT GPL distribution as you noted. So the versioning would have > to use the aliversion in the names of the .gpr files, possibly with a > versionless symlink to the default versioned project file, e.g.: > > /usr/share/ada/adainclude/gtkada2.14.2.gpr > /usr/share/ada/adainclude/gtkada2.18.gpr > /usr/share/ada/adainclude/gtkada.gpr -> gtkada2.14.2.gpr That would mean version-dependent gpr files. This is what we have now. BTW, it probably won't work, because the project name is checked against the file name. The idea is that the name of a gpr file never changes, so you do not need to modify your gpr file each time a new gtkada version comes. You don't need to modify it for another Linux. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
|
Next
|
Last
Pages: 1 2 3 Prev: Call for papers: SETP-10, USA, July 2010 Next: TXL Grammar for Ada 2005 |