Bug#761135: archdetect: package rename/package-type change breaks d-i builds
[Cyril Brulebois]
> Of course a failing d-i build means src:debian-installer FTBFS. What
> else would that be?
Thanks for asking. To me, it could also mean a failing to build a ISO
with d-i udebs on it. But I had already tested ISO builds, and thus
was a bit unsure what was failing for you.
> Please explain how you managed to build installation images with a
> failing d-i build.
The ISO build system understand and handle the provides header, and
the ISO build is working as before the deb was introduced, as can be
seen on for example
<URL: http://lists.alioth.debian.org/pipermail/debian-edu-commits/2014-September/008537.html >.
> I'm not sure why you're insisting on the renaming. Please explain
> why you did that (see my first follow-up).
Somehow I get the impression that you do not really want to understand
why I did this change but just want a set of arguments to brush off
before reverting it, but I hope it is just a language barrier issue.
Anyway, here are the explanation why I introduced a archdetect deb and
how the change have been tested so far.
* A archdetect deb allow users on installed systems to figure out
which kernel the installer want to install on a given machine.
* The need for a normal deb for archdetect have been on the TODO list
for years, see for example debian-installer/doc/TODO listing this
entry in the "Post-etch goals" list:
- real deb from archdetect udeb (luther)
* The deb was already present in Ubuntu, under the name
archdetect-deb. Adding the deb in Debian can reduce the diff with
Ubuntu.
* We normally in Debian name udebs with a -udeb postfix, and name
packages after the binary they contain. Diverting from this common
naming scheme should be avoided. This I decided to use the
sensible name for the deb in Debian, and switch the udeb to have
the name we commonly use for udebs in debian, <package>-udeb.
* I knew d-i (anna-install and the rest of the d-i installation
system) would handle the provides header, and tested this on a
fresh install in a virtual machine before commiting the change.
* I checked how many udebs were depending on archdetect (6, if I
recall correctly), and new they would cope just fine with the
change.
* Knew the Debian archive would handle the rename, as udebs and debs
have different name spaces, and we use the provides method with
several library udebs already.
So the change was tested and the installer was working as it should
also after the rename. The only thing I didn't test was building the
debian-installer source package itself, which broke as you correctly
observed. The simple fix is to replace archdetect with
archdetect-udeb, but a more proper fix is probably to teach the build
of d-i initrds to understand the provides header, to ensure similar
issues do not arise in the future.
The simple fix is in look like this (commits
50506fe7643ecf44ccc388dab04e3c7fba085dcd and
9925e98994c4406b616e21d9db2703eca5b6ce32) in the debian-installer git
repo:
diff --git a/debian/changelog b/debian/changelog
index a6d89a2..f732bcc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -29,6 +29,10 @@ debian-installer (2014XXXX) UNRELEASED; urgency=low
- raise the xorriso build dependency to >= 1.3.2-1~ on these
architectures, for compatibility with grub-mkrescue in GRUB 2.02
+ [ Petter Reinholdtsen ]
+ * Adjust package lists to cope with the archdetect->archdetect-udeb
+ rename, and remove the rename item from the TODO (Closes: #761135).
+
-- Cyril Brulebois <kibi@debian.org> Sat, 02 Aug 2014 02:59:35 +0200
debian-installer (20140802) unstable; urgency=low
diff --git a/build/pkg-lists/base b/build/pkg-lists/base
index 4650288..12c66e2 100644
--- a/build/pkg-lists/base
+++ b/build/pkg-lists/base
@@ -2,7 +2,7 @@
# get them.
busybox-udeb
anna
-archdetect
+archdetect-udeb
cdebconf-udeb
cdebconf-priority
di-utils
diff --git a/build/pkg-lists/cdrom/m68k.cfg b/build/pkg-lists/cdrom/m68k.cfg
index 61d6947..5ef5b33 100644
--- a/build/pkg-lists/cdrom/m68k.cfg
+++ b/build/pkg-lists/cdrom/m68k.cfg
@@ -7,4 +7,4 @@ console-setup-amiga-ekmap
console-setup-ataritt-ekmap
console-setup-udeb
kbd-udeb
-archdetect
+archdetect-udeb
diff --git a/build/pkg-lists/hd-media/m68k.cfg b/build/pkg-lists/hd-media/m68k.cfg
index d9c75bb..0b61609 100644
--- a/build/pkg-lists/hd-media/m68k.cfg
+++ b/build/pkg-lists/hd-media/m68k.cfg
@@ -5,4 +5,4 @@ console-setup-amiga-ekmap
console-setup-ataritt-ekmap
console-setup-udeb
kbd-udeb
-archdetect
+archdetect-udeb
diff --git a/doc/TODO b/doc/TODO
index ed6167b..f73f37e 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -147,7 +147,6 @@ Post-etch goals
- low(er) mem (zboob)
- uml for testing d-i (anton)
- post reboot network configuration (cjwatson)
- - real deb from archdetect udeb (luther)
- integrate selinux installation into the installer, for a painless
install (joeyh/manoj?)
- add a xen server task (joeyh)
> Please see my mail about avoiding disruptive changes. This kind of
> changes should have been done at the beginning of the release cycle.
> We're way past the time it's OK to merge such disruptive changes
> with absolutely no coordination, and no test.
I do not really see this a disruptive change. That term is for me
reserverd to larger changes than this. What we talk about here is the
introduction of a new deb, in a way that the archive and the installer
handle just fine. The initrd builder didn't, and I am sorry for not
realising this up front and failing to test it before doing the
change. I had done several tests and believed I had covered all the
important angles.
I do suspect the fact that debian-installer/build/util/get-packages do
not understand provides headers is a bug that should be fixed. If
get-packages had handled provides, I suspect no changes outside the
hw-detect package would have been needed for this change.
--
Happy hacking
Petter Reinholdtsen
Reply to: