[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 <k...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org