jnqnfe <jnq...@gmail.com> (2015-02-27): > Control: retitle -1 Sid d-i's are actually Jessie d-i's
That's no news: unstable is where stuff targeted at testing is staged, and we want the jessie installer to go through there as well. And that's still not a bug… > 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. Why don't you set the variable(s) you want or need in your bootloader? > 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 don't buy your “surely”. > 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. Meh. > 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). I've already answered that anyway. It's not like installing sid is either impossible or even hard as it stands; jessie is just the default. > 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. I already pointed out that jessie is the default. That doesn't mean you can't install something else. See the manual and/or the example preseed file (mirror/suite && mirror/udeb/suite; see logic in net-retriever). > It is much easier if a pre-built Sid copy of d-i is available to just > download. Easier, maybe; worthwhile given that the current flexibility is more than enough for your needs, surely not. > 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, Every user insisting on getting sid really should be able to figure how that's already possible without daily builds. > and secondly, perhaps more importantly, because the daily d-i builds > cannot be downloaded securely due to the lack of signed release data. That's another can of worms, already tracked in other bug reports. > (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. Again, they don't have to. > 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. Or from the network. > 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. A recurring issue is kernel ABI bumps breaking netboot images. Others are OK, so shrug. > We really need to get pre-built non-daily Sid copies of d-i files > available, and on an archive with *signed* hashes. You're saying that a lot in your message… so I'll skip replying to this new instance. > 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. D) Use what's already available. Mraw, KiBi.
signature.asc
Description: Digital signature
