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 <jnq...@gmail.com> (2015-02-26): > > On Thu, 26 Feb 2015 22:07:00 +0100 Cyril Brulebois <k...@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. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1425071179.17708.75.ca...@gmail.com
