Hi folks, as mentioned earlier this month, I had a little proof of concept for Paris Mini-DebConf 2014[1]. I've polished a few things, so here we go.
1. https://lists.debian.org/debian-boot/2014/01/msg00239.html [ I've set reply-to: -boot@ for a few questions I'd like answers to / comments on; -backports@/-cd@/-kernel@ are in cc for information. ] Short summary ============= The idea is to build stable images, pulling a few bits from stable-backports, most notably the linux kernel, for improved hardware support. I'll talk about wheezy later on, but the basics should also work for later stable releases. There are different topics which I believe could be discussed more or less separately. I've emphasized the QUESTIONS in the following sections (only in I/II, later sections should be more informational, and hopefully not controversial). I. How to build and run images ============================== At least 2 source packages need updating: 1. debian-installer, so that one can upload to wheezy-backports, and get extra bits set up, in order to pull the kernel and some kernel modules from wheezy-backports. You can find a few patches for this in my wheezy-backports-v3 branch: http://git.mraw.org/?p=debian-installer.git;a=shortlog;h=refs/heads/wheezy-backports-v3 git://git.mraw.org/debian-installer.git [The top two commits are just there for testing purposes. You can play at home using the following command. I haven't tested other image types just yet: make USE_UDEBS_FROM=wheezy USE_BACKPORTS_FROM=wheezy-backports rebuild_netboot-gtk ] Pulling kernel module udebs from wheezy-backports is easy since they don't exist in wheezy, so apt happily finds and installs them. Pulling some targeted components like the one mentioned below hasn't been investigated yet. [I've been using localudebs/ for now.] QUESTION: How to specify which extra bits to pull from wheezy-backports? 2. net-retriever, which needs to pull regular bits from wheezy, and kernel module udebs from wheezy-backports. Unfortunately, contrary to the above, anna is used here, instead of apt. That means using an overlay (not self-contained) suite like wheezy-backports isn't possible by default. You'll find patches and rationale for them in my backports-v1 branch: http://git.mraw.org/?p=net-retriever.git;a=shortlog;h=refs/heads/backports-v1 git://git.mraw.org/net-retriever.git I'm not yet convinced about “resolve conflicts with backports” vs. “resolve conflicts with stable”. See commit message: http://git.mraw.org/?p=net-retriever.git;a=commitdiff;h=d2de776325e65a667a3c4f3f6901aa2b1bd5ae5f QUESTION: Should we pick a different policy? If we were to pick a handful of packages from backports, how to do that? [Also, see above question.] II. How to install a backported kernel ====================================== Here's what I did for my PoC at Mini-DebConf (warning, not nice): a. I added a finish-install script which would unconditionally enable backports and install a hardcoded kernel package using “apt-get -t wheezy-backports $kernel”. (Yes, this is sad; a reason for this was that wheezy's apt-setup is lacking the backports code entirely.) Why did I do that? One of the first thing we install in /target is the target kernel. At this point, apt-setup hasn't run, so hasn't had a chance to set up extra repositories in sources.list. Even if it did, it's using apt-install, which doesn't know about backports. Now here's another way which doesn't look so scary: b. 1) Make sure the kernel installation step still installs stable's kernel (which might not be functional, but having it shouldn't hurt; and not changing such critical code doesn't look too bad…), and make sure it stores the package name somewhere for later use. 2) Patch apt-setup so that wheezy-backports gets automatically enabled when such an installation medium is detected (e.g. /etc/udeb-backports-source exists). 3) Keep a finish-install script which would use the first two steps to complete the installation. QUESTION: Is there any saner/more straightforward/better option here? QUESTION: How do we make sure we pull the relevant patched packages at this point? (apt-setup comes to mind, ditto for the package possibly containing the finish-install script.) [Also, see questions in the first section.] III. How/When to upload ======================= Probably not before we've uploaded d-i with the same kernel version into unstable, and not before it has entered testing. That would fit the usual backports policy. Also, dak's configuration wants to be adjusted to support backports-like versioning. IV. How to maintain wheezy-backports compared to master ======================================================= Since master both gets kernel config updates (which we want for backports) and many other irrelevant stuff, I'm a bit undecided on how to keep track of wheezy-backports: either cherry-pick relevant stuff from master; or merge regularly, reverting unnecessary bits. I would tend to go with the former. V. How to build official images =============================== That's a topic for debian-cd, and for another day. VI. Thanks… =========== … for reading so far, and even more so if you're about to hit “reply” and send interesting feedback. ;-) Mraw, KiBi.
signature.asc
Description: Digital signature
