[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status and open questions for debian-installer with backports support


Thanks for your comments. I really should have thought about putting
the kernel team in copy but it's been a long write-up…

Ben Hutchings <ben@decadent.org.uk> (2018-08-03):
> This looks rather inefficient.  Maybe not a big deal for the small
> number of udebs though.

That's correct on both count: inefficient but also not a pratical issue.

> (Time to put a more powerful scripting language in the installer?
> Even awk would be a step up!)

I'd rather discuss that separately (too many topics already). The
net-retriever part is mainly going to be used by people preparing the
upload anyway.

> > base-installer
> > --------------
> [...]
> > We could probably modify library.sh to reuse it, but I'd like to have
> > minimal changes (for reasons explained in the very last section). We
> > could probably just iterate over all installed linux-image-'*' packages,
> > pick the one from the src:linux package, and upgrade it from the
> > backports repository.
> You mean the src:linux-latest package, right?

Exactly, sorry for the typo.

> This is kind of unfortunate, but should work.  Even when the set of
> flavours for a architecture is changed, src:linux-latest builds
> transitional packages to support upgrades.

Right, that's what I had in mind, having witnessed the transition from
586 to 686.

> > debian-cd
> > =========
> [...]
> > => It might be nice to have some kind of consistency check, at least
> >    to make sure the ABI is the same for the linux kernel produced by
> >    the d-i build, and for the modules available in the backports
> >    suite. [Note: this might be true for weekly builds too, see recent
> >    complaints/bug reports.] Bonus points if the source version is
> >    checked too, for extra caution.
> It is not a nice bonus, but really important that the source version is
> equal.  Using module udebs older than the kernel image will usually
> (but not always) work, but using newer module udebs will often result
> in unresolvable symbols for some modules.

Right now, we build debian-installer and trigger debian-cd builds under
a udeb freeze, so we cannot be out of sync for alpha releases. That's
why I called it a “bonus” for regular uploads.

But yeah, for weekly builds we don't have such a guarantee, and we won't
have that either for backports (even if we can just coordinate with the
kernel team when we're about to build images with backports enabled).

> > The finish-install script ran as expected, but I ended up with a 4.16
> > kernel from backports in the installed system, as the linux-latest
> > binaries still point to it rather than to 4.17 (presumably because
> > linux/stretch-backports is still Needs-Build on mipsel at the moment).
> That was just forgotten, I'm afraid.  Bastian has just updated linux-
> latest.

Yes, I've seen the git notification pop up on IRC earlier today, thanks!

> >                             Users would have reproducible results over
> >    time, instead of a jumpy target. I don't know debian-cd enough to
> >    determine how feasible it would be. I'm also not sure what would happen
> >    if we had “old” linux-image packages on the ISO, and “newer” ones on
> >    mirrors.
> If they *do* enable network sources then they should get the latest
> version.  This is not so different from installing stable and getting a
> security update instead of the version on the installation image.

Right, that seems reasonable.

(I think I was still a bit surprised by having had 4.16 installed with
4.17 running in d-i; which might not work too well… The other way
around, i.e. a higher version installed, shouldn't be an issue though.)

> > Open questions
> > ==============
> > 
> > Now that I've explained (in length…) how it works, I think it's high
> > time we define what our target is.
> > 
> > Due to the volatility of a backports suite, I would tend to not even try
> > to support netboot.
> Agreed.
> >                     Aiming for a least a netinst image would look good
> > to me. If we can manage that, we can probably also produce a CD1 for
> > those who want to have more packages than just what's on a netinst (I've
> > had at least one such request). I'm not going to debate how many
> > desktops we should have CD1 for, that's really not my call. I'll just
> > mention that size constraints might be tricky since we'll have both the
> > linux-image packages for the base suite and those from the backports
> > suite. The whole DVD/BR thing is probably entirely overkill.
> As I understand it, CD#1 is already fairly useless for non-networked
> (or limited network) installations and DVD#1 is a lot more useful.

OK, I'll leave that up to Steve and the images team anyway.

> > => Choice to make: netinst and maybe CD1(s)? Something else?
> > 
> > It's probably a good idea to consider building matching unofficial
> > image(s) with firmwares embedded. I'm not an expert regarding debian-cd
> > so help is much welcome. Tweaks might be needed to get firmwares
> > installed and/or upgraded from the backports repository, be it to embed
> > them on the image, or to make them available to the installed system.
> Yes, firmware would need to come from backports.
> Since there is no dependency relation between the kernel and firmware
> package, I don't prune old files until they are no longer referenced by
> the kernel version in any supported suite.  So the CD image build would
> only need to use firmware packages from backports, not two different
> versions.

OK, thanks for mentioning this.

I'm not sure about the code path(s) responsible for enabling firmwares
on the installed system based on what was used/available on the
installation image. I hope Steve knows more about that, and will help me
figure out whether some more modifications are needed in some udebs to
make sure we have the right firmware packages/versions installed.

> [...]
> > Last question: how often do we produce such an image? I don't think it's
> > reasonable to do that every time a new major version of linux is made
> > available in the backports repository. Doing that once around the middle
> > of the release cycle would look good to me. This would kind of mimic the
> > “and a half” thing we had in the past. Once we get the process right, we
> > might think about doing so another time or two, but we already have limited
> > humanpower to deal with stable point releases and alphas for testing
> > (at least oldstable is gone now)…
> Doing this even once per release is a nice improvement, but I think
> it's not enough to solve the problem of unsupported hardware (even on
> x86).  And I think the more often this is done, the easier it will get.
> Still, I realise that you are likely to end up doing most of the work,
> and only you can decide how much time to spend on it.

Thanks for sharing this as well. I don't spend enough time on hardware
related topics so I didn't realize how much of an issue that can be.

Given how few changes were needed when I forward-ported my patch series,
it might indeed be rather easy to get more builds with newer kernels.

If we manage to get the debian-cd bits correctly, this might even be
very low maintenance.

But for now I'll concentrate on getting a single such release out, just
to make it official we actually did it.

> > => Question: what to advertise/communicate on? One-shot only is probably
> >    a good rule of thumb?
> [...]
> I think what you're proposing is to announce this as a one-off, and not
> to immediately make any promises about regular builds.  If so, I agree.

Thanks for bearing with my poor choice of words. That's exactly what I

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply to: