Philipp Kern <pkern@debian.org> (2016-07-10): > On 2016-07-04 18:08, Cyril Brulebois wrote: > >>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? > > that was the main issue. Apart from the updates part below. OK. > > >>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. > > Where to would we upload d-i? jessie-backports. > Under what name? Not sure I understand the question. If that's for an “jessie+1/2” alternative, I have no proposals right now. > With what content? For src:debian-installer? fork from master, remove everything not fitting backports (package renames etc.), is probably a better idea than trying to backport (mostly) kernel config changes. Later such versions (if needed) can then be prepared by git merging further from master. > Would we re-spin stable d-i plus backports-related changes into > backports? Based on the above reply, no. > Would backports ftp-masters be ok with that? Based on the above reply, that's just the usual “copy most of it, leave changes that don't make sense for stable aside” policy, so I would expect they would be. But right, I didn't ask yet. The installer-$arch/ thing shouldn't have any consequences since it isn't used yet AFAICT; we might need to iron out some bugs though. > I feel somewhat uncomfortable with one-offs that are not being > updated anymore and cannot even be updated if need be because the > kernel will have disappeared by them (as it tracks testing rather > than its own version line). I don't see why we wouldn't be able to update that. Just git merge from master (and pick whatever newer kernel version it depends on), and adjust as I mentioned, done. Note: I don't think it's reasonable to require someone to commit to doing regular updates for this one-off. But anyway, the “cannot” part seems bogus to me, as I've just explained. > > - installed system: as usual for systems with backported packages > > (NotAutomatic & ButAutomaticUpgrades). > > So which metapackages would we need to install to keep track of > new major kernel versions in backports? Hm? linux-image-$arch from src:linux-latest, as usual? KiBi.
Attachment:
signature.asc
Description: Digital signature