(Please keep me cc'd.) Philipp Kern <pk...@debian.org> (2016-07-04): > On 2016-07-04 15:12, Cyril Brulebois wrote: > >Steve McIntyre <st...@einval.com> (2016-07-04): > >>There's something I've been pondering for a while, along with some > >>other folks - it might be useful to do a "jessie and a half" release, > >>similarly to what we did in the etch days. That's *basically* just > >>like a normal jessie release, but with a few key updates: > >> > >> * backports kernel > > > >That's a given. > > Does that mean "kernel from backports"?
Yes. > How would we keep that working given that backports keeps changing? Backports changing isn't an issue AFAICT if we're only publishing a netinst image which has all the kernel bits (kernel udebs), as opposed to netboot. Or are you thinking of other issues? > Would we copy the kernel at the time into a special suite? I don't think that's needed. > How would updates work? Updates to? - d-i: nothing has to change (except if we want to republish a new image with an ever newer kernel version), see above. - installed system: as usual for systems with backported packages (NotAutomatic & ButAutomaticUpgrades). > That is to mean: I can see how this would work as a sort of > continuously built thing whenever the kernel in backports changes and > the supporting d-i changes are committed. But in the terms of a > release seems to be a little hard. > > >> * rebuilt d-i to match that kernel > > > >You know there are patches around for that. > > > >> * X drivers > > > >I don't see backports for them. > > Would it also mean X proper or "just" drivers? Last I did backports for X, backports ftpmasters insisted on not getting just the drivers. So I ended up backporting the whole X stack. I'm not sure what happens in the X world these days (is backporting just drivers feasible and/or desirable), or whether backports ftpmasters would decide otherwise now. (Note: that was 5 years ago.) KiBi.
signature.asc
Description: Digital signature
