Improving in-place upgrades of Ada packages from Lenny to Squeeze
Over the last two weeks I have been testing upgrades of Ada packages
from Lenny to Sid and Squeeze in a chroot. The picture is not as pretty
as it should be. In a nutshell, when you change /etc/apt/sources.list
from lenny to squeeze (unstable, actually) and do "aptitude update", you
end up with a lot of broken packages and must intervene manually to
resolve the problem (i.e. remove the broken packages, install new
versions).
The following packages upgrade seamlessly:
* adabrowse
* adacontrol
* asis-programs
* ghdl
* gnat
* gnat-4.3 deleted, replaced with gnat-4.4
* gnat-gps
* libaws-bin
* libaws-doc
* libgnat{vsn,prj}-dev
* libgnat{vsn,prj}4.3-dev deleted, replaced with gnat{vsn,prj}4.4-dev
* libgtkada2-bin
* libgtkada2-doc
In the case of gnat-4.3 and gnat-4.4, this is because of the "gnat"
package that selects and depends on the default version of the compiler.
In the case of libgnat{vsn,prj}4.3-dev, this is only because I recently
added dummy transition packages, libgnat{vsn,prj}-dev in gnat-4.4 (=
4.4.4-4).
The following packages upgrade seamlessly but can silently cause
third-party packages to FTBFS; this is a violation of the Debian Policy
for Ada[1]:
* libadasockets-dev (see #580907)
The following packages are "obsolete or locally created" and marked as
broken by the removal of gnat-4.3:
* libasis-dev (libasis2008-dev available but not installed)
* libaunit-dev (libaunit1-dev available)
* libaws-dev (libaws2.7-dev available)
* libflorist-dev (libflorist2009-dev available)
* libgnademysql-dev (no replacement available)
* libgnadeodbc-dev (libgnadeodbc1-dev available)
* libgnadepostgresql-dev (no replacement available)
* libgnadesqlite-dev (libgnadesqlite3-1-dev available)
* libgnomeada2-dev (libgnomeada2.14.2-dev available)
* libtemplates-parser-dev (libtemplates-parser11.5-dev available)
* libtexttools-dev (libtexttools2-dev available)
* libxmlada-dev (libxmlada3.2-dev available)
The following packages are "obsolete or locally created" but not marked
as broken (even though they are); in Lenny, they lack a dependency on
gnat-4.3:
* libahven-dev (libahven1-dev available)
* libalog-dev (libalog1-{base|full}-dev available)
* libopentoken-dev (libopentoken2-dev available)
The reason for all this is that when a package libX2-dev Conflicts: with
and Replaces: a package libX1-dev, aptitude does not remove libX1-dev
and install libX2-dev; instead, it marks libX1-dev as broken and leaves
libX2-dev uninstalled. As a consequence, upgrades from Lenny to Sid
currently require manual intervention; this precludes unattended
upgrades. The proper resolution of these dependencies is to remove the
broken packages. The dependency resolver in aptitude never suggests
that; instead all the solutions I've looked at involved holding the
broken packages in their current state, essentially halting the upgrade.
The reason why all packages must change names is to ensure consistency
of programs at the source and binary level; the rules of the Ada
language guarantee that an executable program always consists of object
files that are consistent both with their sources and with one another.
Full details in [1,2].
Given the constraints that:
(a) all -dev packages must change names due to the above;
(b) we would like to make upgrades as seamless as possible, and even
permit unattended upgrades,
can anyone recommend a way to achieve that goal?
[1] http://people.debian.org/~lbrenta/debian-ada-policy.html
[2] http://www.adaic.com/standards/05rm/html/RM-10-1-4.html, clause 5
--
Ludovic Brenta.
Reply to: