Bug#779313: Sid installer broken - wrong branch in apt sources.list
Control: retitle -1 Sid d-i's are actually Jessie d-i's
On Fri, 2015-02-27 at 06:46 +0100, Cyril Brulebois wrote:
> jnqnfe <jnqnfe@gmail.com> (2015-02-26):
> > On Thu, 26 Feb 2015 22:07:00 +0100 Cyril Brulebois <kibi@debian.org> wrote:
> > > d-i installs a jessie system by default; if you want sid, you have to
> > > tell that to d-i. Closing as not a bug.
> >
> > I see, okay. So how is that done exactly?
>
> You want to look at USE_UDEBS_FROM set in debian/rules, and at
> DEBIAN_RELEASE in build/config/common (in debian-installer.git).
>
> The former ends up in /etc/udebs-source in the generated install
> images, and is set to unstable for daily builds.
>
> The latter is set to jessie since that's what gets installed by
> default using said install images.
Right, so to get an installer that will work correctly as a Sid
installer, you have to build a copy as such. This is what I assumed
would be the case when I filed the bug.
My point is that surely the pre-built installer builds available under
Sid in the archives should actually be built for Sid not Jessie.
I was making an assumption here that the pre-built d-i files in the
archives were independent from the normal unstable -> testing transition
that is used for package files, however the information in the
debian-installer page of PTS suggests otherwise. What a pain.
I am not merely trying to get something working only for myself here;
this affects all users of live-build who opt for Sid and the non-live
installer config. (I am not the live-build maintainer, but I have been
contributing a lot to it recently).
live-build downloads pre-built copies of d-i from the archives to bundle
into the image it generates, alongside a copy of all available udebs. We
don't want to have to hack live-build to obtain d-i source, set the
release type and build it, just to ensure the installer will work
correctly for Sid users, if it can at all possibly be avoided. It is
much easier if a pre-built Sid copy of d-i is available to just
download.
I recognise that you mention that daily d-i builds may be built for Sid,
however I am not satisfied with these for two reasons. Firstly, because
not every user is going to be happy with having to use daily d-i builds,
and secondly, perhaps more importantly, because the daily d-i builds
cannot be downloaded securely due to the lack of signed release data.
(live-build does not currently attempt to verify the security of any d-i
file downloads, which has been a long standing issue, however I
submitted a large patch to resolve this a couple months ago which is
currently still under review by maintainer, with no word on when it will
be accepted). I am not comfortable with live-build Sid users being
forced to use the daily builds.
I have developed another concern. I am not nearly familiar enough with
d-i, but I am getting an impression that building the installer might
incorporate some udeb packages directly into that installer, while
others are loaded from the disk as necessary. Is that correct? If so,
could there also be potential compatibility issues using the pre-built
Sid (actually Jessie) d-i with udebs from Sid, as users end up with in
their image generated by live-build (unless they opt for live-build to
use the daily d-i build). I have recently been experimenting a bit with
such an image I built with live-build, and I encountered and reported a
couple of bugs. I am now worried that such compatibility issues may
actually have played a part in the occurrence of those bugs.
We really need to get pre-built non-daily Sid copies of d-i files
available, and on an archive with *signed* hashes. What are your
thoughts on this? I see three options:
A) Decoupling the d-i files from the normal unstable -> testing
transition mechanism, with testing and unstable d-i files being built
independently and uploaded directly to testing or unstable archive
directories respectively. I don't know how big a deal it would be to
accomplish this though.
B) The d-i daily archive also providing non-daily Sid d-i builds
(actually built for Sid, not for the unstable -> testing transition),
with an appropriate signed release file to allow verification of
downloads.
C) The live-build project building these and hosting them somewhere. I
see lots of issues with this option: The live-build maintainer seems
generally very busy, so I doubt he'll want to do this; where would we
host them?; how would we deal with signing them for verification
purposes; why would/should live-build users trust these copies we have
built; etc.
Reply to: